Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Access to display widgets:

    1. The widgets are restricted by website domain (meaning only traffic from a particular domain, like yalemedicine.org or dev.yalemedicine.org can display the widget).

    2. There is a Test and a Production version of the widget. The test widget enables the YNHH team to add “dummy” data to the system for testing purposes. The production widget shows real appointment data from Epic. Access needs to be granted to both widgets.

    3. Access is granted to the widgets by a specific Epic URL (unique to Yale Medicine) and a security key.

  2. Appointment availability for providers:

    1. By default, the Epic widgets will show the next available appointment for the provider, no matter how far the future date is for the appointment. YNHH data suggests that 50% of patients who self schedule appointments further than 30 days in the future will cancel or not show up for the appointment. Epic offers an API (data feed) that will return a provider’s next available appointment.

    2. For Yale Medicine website implementation, we will first call the API to determine if the provider has appointment availability within the next 30 days. If they do, we will show the Epic widget with next available appointments. If they do not, we will show a message encouraging the user to call the Care Center for help scheduling the appointment OR click to view appointments available for other providers in the specialty. See designs.

    3. Access to the API requires the YNHH team to add the YM web servers to an “allow list”, create a security key, and provide several other security parameters that need to be included in the API call.

Noteinfo

Anchor
api-limit
api-limit
Based on the API documentation from Epic, the API should only be used to call data for seven days in advance, but it has the ability to call for up to 30 days. Tests show that calling data for 30 days often takes up to three seconds to return information, which is at the limit of what users will tolerate. To accommodate this limitation, we are not planning to use the API, but will instead rely on the widget to provide the appropriate messaging for users. [Updated 9/27]

...