CMS - Lighthouse: push more facility service data

swirtSJW commented 3 years ago

User Story or Problem Statement

A data model was proposed in slack for data that could be sent to lighthouse related to facility services. https://dsva.slack.com/archives/C0FQSS30V/p1612499498413400?thread_ts=1610129900.071700&cid=C0FQSS30V

There was a request to change some of the data structure farther down in the thread here https://dsva.slack.com/archives/C0FQSS30V/p1613073430024100?thread_ts=1610129900.071700&cid=C0FQSS30V

Current Model

{
  "detailed_services": [
    {
      "name": "Audiology and speech",
      "active": true,
      "description_national": "<p>We diagnose and treat conditions...</p>\r\n",
      "description_system": "<h3>Audiology at VA...</h3>",
      "service_api_id": "audiology",
      "appointment_leadin": "<p><em>Contact us to schedule, reschedule, or cancel your appointment. If a referral is required, you'll need to contact your primary care provider first.</em></p>\r\n",
      "appointment_phones": [
        {
          "type": "tel",
          "label": "Main phone",
          "number": "800-329-8387",
          "extension": null
        }
      ],
      "referral_required": "true",
      "walk_ins_accepted": "false"
    }
  ]
}

Proposed Model

{
  "detailed_services": [
    {
      "name": "Audiology and speech",
      "active": true,
      "changed": "2021-02-04T22:36:49+00:00", // NEW
      "description_national": "<p>We diagnose and treat conditions...</p>\r\n",
      "description_system": "<h3>Audiology at VA...</h3>",
      "service_api_id": "audiology",
      "appointment_leadin": "<p><em>Contact us to schedule, reschedule, or cancel your appointment. If a referral is required, you'll need to contact your primary care provider first.</em></p>\r\n",
      "online_scheduling_available": true, // NEW
      "path": "https:\/\/va.gov\/erie-health-care\/locations\/erie-va-medical-center\/audiology-speech", // NEW
      "appointment_phones": [
        {
          "type": "tel",
          "label": "Main phone",
          "number": "800-329-8387",
          "extension": null
        }
      ],
      "referral_required": true, // Changed to boolean value
      "walk_ins_accepted": false // Changed to boolean value
    }
  ]
}

Acceptance Criteria

VAMC Facility Health Service data pushed to lighthouse now includes

[ ] changed - containing the datetime value for when the node was last updated
[ ] online_scheduling_available - containing a boolean true / false value from the field_online_scheduling_availabl field
[ ] path - containing the fully qualified path for the service on va.gov (See note below)
[ ] referral_required - updated to push the boolean true/false value instead of a string
[ ] walk_ins_accepted - updated to push the boolean true/false value instead of a string

Note: the path wasn't originally going to include the va.gov domain but lighthouse asked to include this. However, I'm unclear as to how this has value given the fact these pages aren't live on the front end. Perhaps @swirtSJW can shed some light on why we're including a URL that can't be accessed.

Implementation steps

swirtSJW commented 3 years ago

Initial covid related data being extended as a priority item here https://github.com/department-of-veterans-affairs/va.gov-cms/issues/4484

I updated the spec above to reflect what came out of covid.

swirtSJW commented 2 years ago

This should not be concerned with pushing other service types. That is accounted for with #8019 This is only about pushing more data (phones, leadin, hours....)

JayDarnell commented 1 year ago

Work has been done in #10454 to push additional service types. But that PR does not add additional fields to each service. That work would need to be done here.

JayDarnell commented 1 year ago

Updated discussion on proposed data model: https://dsva.slack.com/archives/C02BTJTDFTN/p1664383503541379

JayDarnell commented 1 year ago

This is the proposed model

{
  "detailed_services": [
    {
      "name": "Audiology and speech",
      "active": true,
      "changed": "2021-02-04T22:36:49+00:00", // NEW
      "description_national": "<p>We diagnose and treat conditions...</p>\r\n",
      "description_system": "<h3>Audiology at VA...</h3>",
      "service_api_id": "audiology",
      "appointment_leadin": "<p><em>Contact us to schedule, reschedule, or cancel your appointment. If a referral is required, you'll need to contact your primary care provider first.</em></p>\r\n",
      "online_scheduling_available": true, // NEW
      "path": "\/erie-health-care\/locations\/erie-va-medical-center\/audiology-speech", // NEW
      "appointment_phones": [
        {
          "type": "tel",
          "label": "Main phone",
          "number": "800-329-8387",
          "extension": null
        }
      ],
      "referral_required": "true",
      "walk_ins_accepted": "false"
    }
  ]
}

JayDarnell commented 1 year ago

Additional feedback from the lighthouse team suggested:

Making the path a fully qualified url
Changing any "false" or "true" strings to their boolean equivalents: true or false

swirtSJW commented 1 year ago

Note: the path wasn't originally going to include the va.gov domain but lighthouse asked to include this. However, I'm unclear as to how this has value given the fact these pages aren't live on the front end. Perhaps @swirtSJW can shed some light on why we're including a URL that can't be accessed.

I believe this should not be the url of the service (because there is none) or even the system services page but the page that is created by hand, about the service / program (example).

What I am not clear on is how we would look up to see which have pages that exist. There is nothing that connects them other than a link in the blobby text.

Possible solutions:

Provide the url for the facility service page with the fragment https://www.va.gov/pittsburgh-health-care/locations/fayette-county-va-clinic/#podiatry
- risk = minimal It would always get them to the right facility. The accordion auto-opens but does not reliably jump the page to it. We would have to sure that our fragment "appender", matches the code of the FE that sets the id.
Provide the url for the services page with the fragment. https://www.va.gov/pittsburgh-health-care/health-services/#pharmacy
- risks = same as above. Additional confusion is added because it puts veterans on system page rather than a facility page.
Search for a VAMC Detail page that matches the system and provide that url if it exists and is published. (if they mis-named the detail page, we would miss it)
- Risk is high that we might not find the page to send them to, even if it exists. Risk increases if a service is renamed and differs from the title put on the VAMC Detail page.

swirtSJW commented 1 year ago

@kmariepat-cityfriends We should probably discuss ^^^ with Dave C as there are pros and cons and it would be good to get clarity on what we are trying to achieve and why.

omahane commented 1 month ago

@davidmpickett At the Facilities/Lighthouse sync, we talked about the referralRequired field. It turns out we did some work for the service location change that is not going to be needed in Lighthouse v1, around the online scheduling and office visits.

      // These three fields are repeated here to support Facilty API V0
      // for Covid-19 Vaccines.
      $service->referral_required = $this->getReferralRequired();
      $service->walk_ins_accepted = $this->officeVisits;
      $service->online_scheduling_available = $this->isOnlineSchedulingAvail;

referral_required is among the fields no longer at the service level for Lighthouse (LH), but we didn't account for it in the service location change. That is, right now we are grabbing the data from the service and putting it in the service location for referrals, meaning that it's set at the service level, and propagated through all the service locations data in the services push to LH.

I don't recall ever talking about whether we wanted to change that and even, perhaps, that we didn't want to change it. But it's odd that LH now represents a data model that included referral data more granular than our own, given that we're the source of the data.

davidmpickett commented 1 month ago

@omahane I'm not sure exactly what you are saying

1) We are taking service-level information (ReferralRequired) from Drupal and converting it to Service Location-level information as part of our post API queue? Maybe this was done as part of #17114?

2) Lighthouse changed their data model (as part of v0->v1) to have have referral required be at the Service Location-level. And now they are confused why we are sending it at the Service level because we were the ones who told them a year ago that we thought it would be Service Location level data?

davidmpickett commented 1 month ago

If it's #2 this is likely a product of Steve Wirt communicating this idea a year ago when we were still in early drafts of the VBA content model. Referral was included as something that might be indicated at the Service Location level rather than the Service level. It was last fall that we decided that didn't make sense because referral was only really applicable to VAMC health services, not Non-Clinical services or any VBA services.

davidmpickett commented 1 month ago

That being said, I don't think this decision is necessarily final. It might make sense to migrate Referral Required to Service Location-level, now that 1) All Appointment fields are hidden on Non-Clinical Services anyway. 2) We know how to run these data migrations and do the relevant form alters. We could hide on VBA and migrate the facility health service info to service locations.

There's a Product/Stakeholder question in here of whether being able to indicate this information at the Service Location level vs Service level is necessary or desirable.

omahane commented 1 month ago

@davidmpickett

If it's #2 this is likely a product of Steve Wirt communicating this idea a year ago when we were still in early drafts of the VBA content model. Referral was included as something that might be indicated at the Service Location level rather than the Service level. It was last fall that we decided that didn't make sense because referral was only really applicable to VAMC health services, not Non-Clinical services or any VBA services.

It's more like 2. They were confused because they moved ReferralRequired to Service Location. We never did. In fact, I didn't do anything with ReferralRequired. Steve prepared for v1 by sourcing the service-level ReferralRequired and putting it in the cms-overlay at the service location level in addition to passing it at the service level.

With v0's sunset, LH doesn't need referralRequired, officeVisits or isOnlineSchedulingAvail at the service level (though it won't break anything to send it, either).

I figured there must have been some conversation about this, likely between you and Steve, among others, so I wanted to confirm that this was intentional and not an oversight.

department-of-veterans-affairs / va.gov-cms