First click-through of the parents' clinic booking journey by malross · Pull Request #223 · NHSDigital/manage-vaccinations-in-schools-prototype

malross · 2026-03-17T14:26:20Z

Parents' booking journey is in the /book-into-a-clinic route. Other, earlier routes /clinic-booking and /clinic-appointment will likely be dropped in favour of that but are kept for reference for now.

Note: various aspects are currently hard-coded, including:

the lack of iteration for multiple children
the lack of matching to existing child records (or listing of eligible vaccinations)
the set of health questions presented
the details in the check answers page

Some of these things are part-coded, but need debugging.

Next steps planned:

Generate the appointment sub-journey in a method, similar to the health question one, creating steps for all N appointments in one go
- Create all appointment models themselves in advance (culling existing ones or creating new ones as needed)
- getAppointmentQuestionPaths(booking_uuid, data.wizard)
  - This will see how many appointments are on the context and have that booking ID and loop to generate the wizard paths for them
- Reintroduce the update method to respond to confirmed submission from the check-answers page, putting the appointments into the booking at that point (if not at the point of their creation?) and the booking into the global context
Do the same for the health questions, generating the paths for all appointments
Make better use of existing classes e.g. replace the unmatchedXxxx fields in ClinicAppointment with a Child object

Each booking, which will have a unique booking reference number, has one or more appointments. This corresponds to one or more children being booked into a clinic by the same parent and in the same booking flow. Models are not yet hooked up to anything.

Various aspects of the appointments could still be improved (e.g. choice of programmes), but some of it is limited by the lack of clinic session details in the models (e.g. start and end times, slot lengths, etc.)

Squash this commit. As it stands, data file generation fails with a circular reference. This is because I made the mistake of composing the objects I was creating in a hierarchy rather than using IDs as foreign keys. I'll fix that in the next commit.

In short, npm run create-data now runs without encountering infinite loops. Replaced aggregation of actual model objects with use of object IDs and getters to return the actual objects. Also in this commit, have improved the logic for matching children's ages to the clinic's programme(s) and choosing non-surprising parental relationships (albeit without attempting to make siblings have the same last name).

This replaces the previous use of Other to indicate foster carer status.

This is jsut based on the Move class/controller, so nothing major yet. Plus, I've commented out the Update method for now. Not sure yet whether I need to do the clinic appointments too. Suspect I will, of course, but need to get more comfortable with relative routes first.

Nothing more than a call to inspect on the response.locals

To be honest, not sure we should be using faker calls in the model or that we even need to pass the booking reference as a parameter to the constructor, but that tidy up can come later, if at all.

Previously, any pages trying to list the full set of records of a given type would most likely fall over when attempting to stringify the json, as no context was found in the array itself.

Out-by-one error.

Dummy view only at this point, dumping the JSON to the page.

And make them into full Parent objects, so that we get all of the other properties that I'd missed and can lean on things like summaryRows in the views.

This doesn't yet include any option to edit the values. I'm just exploring how to get values showing right now.

This is just a first pass at the UI. Styling and spacing need work, and the buttons don't actually go to any sensible routes, but that can come later.

There are other supporting changes in this commit e.g. addition of a slug to the SessionPreset objects, but part of the work in the /start view for book-into-a-clinic is likely to be abandoned; I'd gone too far down the route of copying the consent start page design and not been following my own journey design. I'll fix that.

There's also a lot of fleshing out of the book-into-a-clinic controller and its routes, though there's still work to do to get the child_index parameter sorted. Either that or I'll drop that part of the route and rely on session data to track it instead. Probably the latter. Note that one particular element that almost certainly won't work in the view right now is the use of array indexing in the inputs' decorate values. I may want to store the current appointment separately somehow and only add it to the booking model when complete and moving onto the next child's appointment. May need a separate route defined for the starting page of the appointment sub-flow, where I can create that object, just as I do for the booking object in the <preset_slug>/new route.

Prior to this, there were plenty of %s values still appearing in the page, esp. for the child's name. This commit signals a shift in the booking vs. appointment paradigm on the wizard context. I'm now holding 2 models on this wizard context in this journey: one ClinicBooking and one ClinicAppointment. The latter will be built over the course of the appointment-related pages and only when that's complete will it be added to the booking. One thing this gives us is the appointment's UUID, which we can use in the routes rather than a child_index. The logic to get the appointment UUID into the routes will need changing when it comes to looping to the second appointment, but it essentially ignores the wizard journey's paths.next to build the URI of the first appointment step with the appointment_uuid injected. Maybe there's a better way to do this, but I don't know it yet. Accordingly for the changes to the set of models held on the wizard context, we're now also recording form values in req.body.booking or req.body.appointment, with those values being propagated to the relevant model in updateForm.

Note: this is not a working journey yet, but I'm committing before I end up adding an overwhelming amount in one go. (It's already too much, to be honest.) Changes in this commit: * Addition of clinic-finding and slot-booking views, plus parent detail views and health questions. Health questions not working yet due to selection of vaccines not binding properly (need to investigate correct use of decorate for checkboxes()) * Introduction of a transaction object in the wizard context, for tracking transient journey data that doesn't need to be stored in the model e.g. number of children, location entered for search, etc. This will still need to be keyed to the booking uuid to avoid multi-user conflicts, however. * Various page text fixes, including access to the current child's first name for inclusion in question titles * Tenative change to how parent details are stored, as we really need to store them on the parent object in all appointments, not just one. So there's a parentTel getter/setter pair in ClinicBooking now that I might need to replicate for all relevant properties of the parent; or perhaps just offer a Parent object getter/setter pair and push changes to the ClinicAppointment objects (though what we should get back for parental responsibility is another matter, as that varies by appointment)

Pausing the dynamic health question stuff for now, to focus on hard-coded health questions that can be used for imminent research.

Still uses the health-question.njk view, but the journey definition is hard-coded rather than using the code to generate the sequence of views. This is for expediency, as I need to hook up the addition of appointments to the booking and sort out the looping and reestablishment of the appointment uuid in the route.

This doesn't yet include the health questions, but will probably need to. Some redesign to be done there.

This is based on a quick review with Ben Weedon and follows the pattern established by the ethnicity questions in the consent parent journey.

I've moved away from the somewhat poorly-focused "Child 1 of 2" wording to be clearer that the page is: 1. part of the appointment process 2. for a specific, fully-named child I might yet take use of the child's first name out of other parts of the pages.

Yes, it's only hard-coded, but it's needed for a research session.

One link per primary programme (aka session preset).

This commit is the start of work to support iteration through multiple children (or appointments) in the parents' clinic booking journey. It will allow us to map out the full wizard journey but still needs to be supported by dynamic generation of the appointment journey pages for each of the appointments we create (as well as dynamic generation of the health question pages for each of those appointments).

This commit moves the Parent object to the ClinicBooking, removing it from the ClinicAppointment (but adding parental relationship properties to the appointment). This should simplify various areas, removing the need to propagate contact details to multiple appointments in the same booking. The changes here required changes to the generation of fake data too and triggered a bit of fixing.

This isn't the best solution, but is only intended as a quick way to address the need for parental responsibility. See the comment in parental-responsibility.njk for a better proposed solution.

paulrobertlloyd · 2026-03-18T10:39:01Z

Once you’re happy with the clinic booking flow, you can pop a link to it on the prototype homepage.

paulrobertlloyd · 2026-03-18T10:40:50Z

app/controllers/book-into-a-clinic.js

+
+export const bookIntoClinicController = {
+  // Load the preset into locals
+  read(request, response, next, session_preset_slug) {


Worth taking a look at

manage-vaccinations-in-schools-prototype/app/controllers/parent.js

Lines 20 to 28 in fbfbd2a

const serviceName = 'Give or refuse consent for vaccinations'

response.locals.assetsName = 'public'

response.locals.serviceName = serviceName

response.locals.headerOptions = {

service: {

text: serviceName

}

}

Setting the serviceName and assetsName means you can give this parent facing flow it’s own name, use the standard (narrower) page width, and not show SAIS-facing navigation.

Ah, thanks. Hadn't got to that, but was wondering why I had the SAIS team's navigation in the header.

@paulrobertlloyd does the service name need to be non-localised?

It could be, but so far this service name is not used in many other places.

The dates are still hard-coded, but at least make sense now (copy-paste error spotted by a parent in a research call).

paulrobertlloyd · 2026-03-18T11:49:03Z

app/views/book-into-a-clinic/form/vaccination-choice.njk

+  {{ checkboxes({
+    fieldset: {
+      legend: {
+        text: __("clinicBooking.vaccinationChoice.vaccinations.label", firstName)


Perhaps add size: "m" to increase the prominence of this legend on the page

paulrobertlloyd · 2026-03-18T11:49:50Z

app/locales/en.js

+      hits: {
+        label: 'Choose one of the following:'
+      },
+      tryAgain: 'None of these - try another town, city, or postcode'


Suggested change

tryAgain: 'None of these - try another town, city, or postcode'

tryAgain: 'None of these – try another town, city, or postcode'

Is that an em dash replacing a hyphen? Hard to tell in a monospace font.

Still need to do the same for the health questions, but there are other missing pieces of the puzzle to address before I can get that working.

As requested in PR #223

This means swapping individual checkbox values for a Boolean or taking _checked out of arrays where there are multiple checkboxes - in both the booking and appointment models.

malross added 30 commits March 11, 2026 17:49

Generate fake data for clinic bookings and their appointments

415302c

Various aspects of the appointments could still be improved (e.g. choice of programmes), but some of it is limited by the lack of clinic session details in the models (e.g. start and end times, slot lengths, etc.)

Create fake parents with the Fosterer relationship

bd73691

This replaces the previous use of Other to indicate foster carer status.

Add dump-only views for show and list on clinic bookings

b2b6f05

Nothing more than a call to inspect on the response.locals

refactor: De-duplicate the clinic booking reference generation

c2a636f

To be honest, not sure we should be using faker calls in the model or that we even need to pass the booking reference as a parameter to the constructor, but that tidy up can come later, if at all.

Allow inspect() to remove context from arrays as well as single records

ecc6fad

Previously, any pages trying to list the full set of records of a given type would most likely fall over when attempting to stringify the json, as no context was found in the array itself.

fix: Generate expected number of fake clinic bookings

18f67e2

Out-by-one error.

fix: redirect to correct route format after updating a clinic booking

1d22fed

Add clinic appointment faked data, routes and controller

e04a84d

Dummy view only at this point, dumping the JSON to the page.

Move parent details for clinic bookings into clinic appointments

2648305

And make them into full Parent objects, so that we get all of the other properties that I'd missed and can lean on things like summaryRows in the views.

Present details of a single clinic appointment in a new view

f23e514

This doesn't yet include any option to edit the values. I'm just exploring how to get values showing right now.

Show the details for a single clinic booking

1b94bca

This is just a first pass at the UI. Styling and spacing need work, and the buttons don't actually go to any sensible routes, but that can come later.

Minor: typo fixes and comments around clinc booking

3dc71f9

Pausing the dynamic health question stuff for now, to focus on hard-coded health questions that can be used for imminent research.

Add hard-coded check answers page for clinic booking

c588aca

This doesn't yet include the health questions, but will probably need to. Some redesign to be done there.

Add confirmation page for clinic booking journey

dd33bda

Use correct heading levels on clinic booking check answers page

8f0b79d

Move clinics' health questions to after booking confirmation

bd1d65e

This is based on a quick review with Ben Weedon and follows the pattern established by the ethnicity questions in the consent parent journey.

Fix the forking for health questions in clinic booking

0c4cdec

Use HPV, not MMR, immune system health question.

364d8a7

Yes, it's only hard-coded, but it's needed for a research session.

Fix misplaced HTML in clinic booking's check answers page

b8d57f3

Fix all linter issues in clinic booking

11151e0

malross requested a review from paulrobertlloyd March 17, 2026 14:26

paulrobertlloyd temporarily deployed to mavis-protot-clinic-boo-i8zvab March 17, 2026 14:28 Inactive

malross added 4 commits March 17, 2026 15:13

Add homepage links for booking into clinic journeys

c76abbc

One link per primary programme (aka session preset).

Add a parental responsibility block in the clinic booking journey

031b3b0

This isn't the best solution, but is only intended as a quick way to address the need for parental responsibility. See the comment in parental-responsibility.njk for a better proposed solution.

paulrobertlloyd reviewed Mar 18, 2026

View reviewed changes

Fix hard-coded date order in clinic booking

996f7d8

The dates are still hard-coded, but at least make sense now (copy-paste error spotted by a parent in a research call).

paulrobertlloyd temporarily deployed to mavis-protot-clinic-boo-i8zvab March 18, 2026 10:59 Inactive

malross added 2 commits March 18, 2026 11:22

Hide SAIS team navigation in parent's clinic booking journey

a4b251f

Fix branching around parental responsibility in clinic booking

e419409

paulrobertlloyd temporarily deployed to mavis-protot-clinic-boo-i8zvab March 18, 2026 11:24 Inactive

paulrobertlloyd reviewed Mar 18, 2026

View reviewed changes

Fix the branching for contact preferences in clinic booking

fd82bbc

paulrobertlloyd temporarily deployed to mavis-protot-clinic-boo-i8zvab March 18, 2026 13:31 Inactive

Iterate over multiple appointments in clinic booking journey

e57d6ad

Still need to do the same for the health questions, but there are other missing pieces of the puzzle to address before I can get that working.

paulrobertlloyd temporarily deployed to mavis-protot-clinic-boo-i8zvab March 18, 2026 15:43 Inactive

malross added 3 commits March 19, 2026 10:54

Increase prominence of vaccine choice heading in clinic booking

2cee5f9

As requested in PR #223

Sanitise any _unchecked values coming from the clinic booking process

c80616c

This means swapping individual checkbox values for a Boolean or taking _checked out of arrays where there are multiple checkboxes - in both the booking and appointment models.

Fix linter issue with unused class import

a32ea08

paulrobertlloyd deployed to mavis-protot-clinic-boo-i8zvab March 19, 2026 12:10 View deployment

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First click-through of the parents' clinic booking journey#223

First click-through of the parents' clinic booking journey#223
malross wants to merge 42 commits intomainfrom
clinic-booking

malross commented Mar 17, 2026 •

edited

Loading

Uh oh!

paulrobertlloyd commented Mar 18, 2026

Uh oh!

paulrobertlloyd Mar 18, 2026

Uh oh!

malross Mar 18, 2026

Uh oh!

malross Mar 18, 2026

Uh oh!

paulrobertlloyd Mar 18, 2026

Uh oh!

paulrobertlloyd Mar 18, 2026

Uh oh!

paulrobertlloyd Mar 18, 2026

Uh oh!

malross Mar 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	const serviceName = 'Give or refuse consent for vaccinations'

	response.locals.assetsName = 'public'
	response.locals.serviceName = serviceName
	response.locals.headerOptions = {
	service: {
	text: serviceName
	}
	}

	tryAgain: 'None of these - try another town, city, or postcode'
	tryAgain: 'None of these – try another town, city, or postcode'

Conversation

malross commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paulrobertlloyd commented Mar 18, 2026

Uh oh!

paulrobertlloyd Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

malross Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

malross Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

paulrobertlloyd Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

paulrobertlloyd Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

paulrobertlloyd Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

malross Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

malross commented Mar 17, 2026 •

edited

Loading