[Bug] Incorrect cancel workflow for a Cerner Booked Appointment

[ldelacosta]

Summary

When a user cancels a Cerner booked appointment, the workflow is not correct. The user should receive a cancel confirmation screen for a booked appointment (not a request). After the user cancels the appointment, it ends up on the Pending list view.

Specs

• Device: Mac
• Browser: Chrome

Steps to Reproduce

Test user: judy.morrison@id.me

1. Go to: https://staging.va.gov/my-health/appointments/CERN53785039
2. Click Cancel

Actual Result

https://github.com/user-attachments/assets/f3fda882-8e8b-462b-af60-8325b391726f

Desired Result

The user should receive the correct cancel confirmation screen for booked appointment not request.

Definition of Done

• [ ] Desired result is achieved and/or document decisions made
• [ ] Relevant documentation is updated

---

[ryanshaw]

@ldelacosta I've looked into this a little bit but it would be useful to have a new booked Cerner appointment on staging to recreate/reproduce this behavior.

The behavior I can determine for now is:

• A booked Cerner appointment is displayed on upcoming appointment list
• When a user choses to cancel, they are presented with the cancel request workflow
• The appointment is then displayed as a cancelled request in the cancelled request list:

https://staging.va.gov/my-health/appointments/CERN53785039

[ryanshaw]

Waiting on staging issues around Cerner appointments to be resolved.

[ldelacosta]

It looks to be that the Cerner booked appointments are treated as Pending:

"data": {

        "id": "CERN53785039",

        "type": "appointments",

        "attributes": {

            "id": "CERN53785039",

            "kind": "clinic",

            "status": "cancelled",

            "locationId": "668",

            "start": "2024-08-28T16:30:00Z",

            "end": "2024-08-28T17:00:00Z",

            "requestedPeriods": [

                {

                    "start": "2024-08-28T16:30:00Z",

                    "end": "2024-08-28T17:00:00Z"

Notified the VPG services team. Waiting for a response.

[ldelacosta]

Not an issue on our end. OH is sending requested period dates in the response. We will need to make updates in FE to filter the appt (booked vs. requests). Closing out the ticket.

[ryanshaw]

Current Behavior

When a user cancels a the booked Oracle Health appointment, the appointment is then considered a cancelled request within VAOS. This is because VAOS uses the following logic to determine whether or not the appointment was originally a request or a CC request:

function getAppointmentType(appt) {
  if (appt.kind === 'cc' && appt.start) { // if kind is CC and has start time is ccAppointment
    return APPOINTMENT_TYPES.ccAppointment;
  }
  if (appt.kind === 'cc' && appt.requestedPeriods?.length) { // if kind is CC and has requestPeriods present is ccRequest
    return APPOINTMENT_TYPES.ccRequest;
  }
  if (appt.kind !== 'cc' && appt.requestedPeriods?.length) { // if kind is NOT cc and has requestPeriods present it is a request
    return APPOINTMENT_TYPES.request;
  }

  return APPOINTMENT_TYPES.vaAppointment;
}

The booked Oracle Health appointment is considered a cancelled request in VAOS because of this specific logic:

  // if kind is NOT cc and has requestPeriods present it is a request
  if (appt.kind !== 'cc' && appt.requestedPeriods?.length) { 
    return APPOINTMENT_TYPES.request;
  }

Desired Behavior

When a user cancels a booked Oracle Health appointment, the appointment should be considered a cancelled appointment not a cancelled request.

• All OH appointments will have a requestedPeriods object
• Booked OH appointments will have a start and end timestamp

Booked OH appointment

• Has requestedPeriods
• Has start timestamp
• Has end timestamp

Cancelled booked OH appointment

• Has requestedPeriods
• Has start timestamp
• Has end timestamp
• Has "status": "cancelled"

We should change logic to:

function getAppointmentType(appt) {
  if (appt.kind === 'cc' && appt.start) { // if kind is CC and has start time is ccAppointment
    return APPOINTMENT_TYPES.ccAppointment;
  }
  if (appt.kind === 'cc' && appt.requestedPeriods?.length) { // if kind is CC and has requestPeriods present is ccRequest
    return APPOINTMENT_TYPES.ccRequest;
  }
  if (appt.kind !== 'cc' && appt.requestedPeriods?.length && !appt.start) { // if kind is NOT cc and has requestPeriods present and has no start time
    return APPOINTMENT_TYPES.request;
  }

  return APPOINTMENT_TYPES.vaAppointment;
}

[JunTaoLuo]

A few things here:

1. I do believe there is a bug on our end so we should probably put this back into Ready/Current Sprint so we can work on this.
2. Actually I think this is a bug on the backend since we should be removing requestedPeriods for Cerner appointments in vets-api. Here's the logic. The reason that this isn't working is that the Cerner appointment linked in the issue doesn't have the expected identifier fields. The question here is whether this is a valid appointment or if our logic for discerning cerner appointments is out of date. @simiadebowale might have a bit more background since he opened the original issue. Though I currently lean towards a BE fix, a bit more discussion here would help clarify whether a FE fix would be more appropriate.
3. As an extra step, maybe we should consider adding new appointment types for cerner and cernerRequest since otherwise these would be considered vaAppointment and request. However, I'm not sure how many more customized logic or future changes will need to be made for cerner appointments so maybe this is unwarranted.

Thoughts?

[ryanshaw]

A few things here:

1. I do believe there is a bug on our end so we should probably put this back into Ready/Current Sprint so we can work on this.
2. Actually I think this is a bug on the backend since we should be removing requestedPeriods for Cerner appointments in vets-api. Here's the logic. The reason that this isn't working is that the Cerner appointment linked in the issue doesn't have the expected identifier fields. The question here is whether this is a valid appointment or if our logic for discerning cerner appointments is out of date. @simiadebowale might have a bit more background since he opened the original issue. Though I currently lean towards a BE fix, a bit more discussion here would help clarify whether a FE fix would be more appropriate.

Ahhh, that makes sense. I am a big fan of moving as much of this logic to vets-api as possible.

3. As an extra step, maybe we should consider adding new appointment types for cerner and cernerRequest since otherwise these would be considered vaAppointment and request. However, I'm not sure how many more customized logic or future changes will need to be made for cerner appointments so maybe this is unwarranted.

I'm currently unsure if we need to make that distinction on the FE, as a VA appointment is a VA appointment regardless of which BE a given facility is using. I'm open to adding, of course, if there is a need.

[JunTaoLuo]

I'm currently unsure if we need to make that distinction on the FE

Perfect, I love not having to do any extra work!

[ldelacosta]

Team is addressing a fix in 92185.