Skedulo Booking Application Release Notes v22.30.0

The Date of Birth validation has been enhanced now so that the system can use the selected appointment date instead of "today" to validate the date of birth or the age of the user. With this enhancement, the users who are younger than the acceptable age limit at the time of booking but would meet it on the selected appointment date would be allowed to create a booking.

To accommodate this use case, the Option Format of the question in Salesforce now accepts the value like appointmentSelectedDate-12years. If the Salesforce's configuration is appointmentSelectedDate-12years instead of today-12years for a question, then the app uses the selected appointment date instead of today to validate the user's age.

From this version, we have enhanced the search logic for the environment variable daysToConsiderByPass i.e the booking window of the booster dose so that the users who have administered their primary course (Dose 1) more than 300 days ago will be able to create a booking for the booster shot starting today (i.e. the day of appointment booking). When the environment variable bypassPreviousDoseDate is enabled, the search logic now calculates the booking window in the following ways:

1. If today - previousDoseDate> daysToConsiderBypass, then the allowed booking time frame is today to (today - minlnterval) + maxInterval.

Let's consider the following scenario: minInterval = 7 days, maxInterval = 14 days, the previousDoseDate is July 20th, and Today (the appointment booking day) is July 25th then, the new booking window is calculated as the following table:

We've introduced a new environment called prefillDataMapper to prefill the information captured on the Screening page and display them on the Patient Details page so that the users do not have to enter the same information again. The data schema of prefillDataMapper is given below:

{
  'destination_question_id1': 'source_question_id1',
  'destination_question_id2': 'source_question_id2',
}
where id1, id2 are the message keys of the questions.

{
  'q.patient.details.group.bookings.parent.firstname': 'q.screening.fname',
  'q.patient.details.group.bookings.parent.lastname': 'q.screening.lname'
}

The booking logic for the /sendReminders, /sendBookingConfirmation, and bookings/confirmationCode endpoints are now updated so that they all throw the Appointment not found error for profane bookings.