FHIR Chat · Publisher: Kroger · smart/scheduling-links

Stream: smart/scheduling-links

Topic: Publisher: Kroger

Josh Mandel (Apr 12 2021 at 15:17):

@Ryan Owens have you had a chance to get started with generating data for SMART Scheduling Links? Want to make sure you have what you need to be productive.

Ryan Owens (Apr 12 2021 at 17:35):

Our development team is working on producing some sample output. Our goal is to be able to provide zipped files to consumers at some point during the event. I don't have a specific date right now but the team knows that consumers are ready to look at our sample whenever we can produce it.

Josh Mandel (Apr 13 2021 at 15:39):

Thanks Ryan! Definitely keep us updated when you know more about the timing -- and of course I should highlight that while starting with a .zip file will let us review data by hand, we're really hoping to get to the point where you can make a testing endpoint available over https, since this is how client apps are designed to retrieve data.

Ryan Owens (Apr 13 2021 at 16:19):

An HTTP(S) endpoint most likely won't be available until perhaps the week after the connectathon at the earliest. We have been given an estimate of one to two weeks for our API gateway team to build their integration for this (since internally we're publishing to a static web site instead of standing up a "proper" RESTful API) and then there would be follow-on red tape to configuring the access for participating consumers. Our original plan was to simply expose a static website, but that is not the direction that was ultimately chosen.

Josh Mandel (Apr 13 2021 at 16:26):

since internally we're publishing to a static web site instead of standing up a "proper" RESTful API

That sounds like a good direction, and very much in line with what SMART Scheduling Links optimizes for !

Ryan Owens (Apr 19 2021 at 15:15):

FYI: The Kroger team is hoping to have sample data available by end of day today. This will be all fictitious data but will represent the structure and granularity we would expect to have when we go to production.

Mike Maass (Apr 20 2021 at 20:21):

Here is a sample for the Kroger team. Right now we have a single location, schedule, and slot file but plan making a slot file for each state. By tomorrow morning we hold to have the site/manifest, slot and location files updated to represent this structure. The data in these files right now is fictitious but the structure and elements are those that we plan to provide.
https://schedulingavbsadev.z20.web.core.windows.net/$bulk-publish

Josh Mandel (Apr 20 2021 at 20:33):

Thanks for sharing this! (And awesome to see that all 2799 locations are in my hometown ;-))

Josh Mandel (Apr 20 2021 at 20:36):

Now that you've had a chance to work on this a bit, any new thoughts on update frequency?

Mike Maass (Apr 21 2021 at 13:16):

Kroger's sample data has been updated to provide a more realistic representation of locations and the slot files have been broken up by state.

Ryan Owens (May 26 2021 at 12:55):

The Kroger team has our API in production and ready for consumers to start checking out. There may be a few fixes yet to come, but it's generally ready for use. To access it, go to https://developer.kroger.com/ and sign up for a developer account. Once you have completed that, go to https://developer.kroger.com/documentation/partner#s-partnership-request and submit a partner request. Request access to the "Vaccine Finder API" in the partner request. Feel free to reach out to me if you need further assistance. You can e-mail me directly at ryan.owens at kroger.com.

Josh Mandel (May 26 2021 at 13:02):

Awesome @Ryan Owens! Will you add the Endpoint info to the registry? https://github.com/smart-on-fhir/smart-scheduling-links/tree/master/publisher-repository

Ryan Owens (May 26 2021 at 15:39):

@Josh Mandel I think that's the wrong link. I did just submit a PR to what I think is the correct registry.

Josh Mandel (May 26 2021 at 16:00):

Ha, sorry (copy/paste error -- fixing my link above). And thanks!!

Rob Brackett (May 26 2021 at 16:55):

@Ryan Owens tried to register for this, but "Vaccine Finder API" is not in the list of APIs I can request at https://developer.kroger.com/admin/user/apps/register/
Am I in the right place?

Ryan Owens (May 26 2021 at 16:59):

It's unlisted. You have to complete the support form and ask to have it added to your profile for access. Our business team wanted it to be "by request only" and not listed for all developers.

Rob Brackett (May 26 2021 at 17:01):

Ah, I see now, the partner URL you sent doesn't go to the right place until after I've registered, so I was looking at the wrong form!

Rob Brackett (May 26 2021 at 17:01):

(The other form is a select list, so I couldn't put in something that's not there.)

Ryan Owens (May 26 2021 at 17:01):

Oh, which link was wrong? I haven't gone through the flow, so maybe I've got something off.

Rob Brackett (May 26 2021 at 17:07):

If you're not logged in, https://developer.kroger.com/documentation/partner#s-partnership-request took me to a different page, which had a "register" link that went to https://developer.kroger.com/admin/user/apps/register/

Rob Brackett (May 26 2021 at 17:08):

Actually, looks like it's working in a private window now, so maybe I just got browser tabs mixed up. Hmmm.

Rob Brackett (May 26 2021 at 17:08):

Sorry for false alarm

Rob Brackett (May 28 2021 at 16:06):

@Ryan Owens I finally got access approved! Thanks for the details on how to navigate the process. I have a few questions after trying it out:

• Do you have any plans to add product or dose information to the schedules? I think I mentioned on this week’s call, but in both New Jersey and Alaska (two states I’m working directly with), focus has shifted a lot from just yes/no availability to getting more details, especially product type. Since many regions of their states have regular availability now, the vaccine finder is helping their case workers and volunteers sign people up, and being able to show people which product is available where (so they can choose) has gone a long way towards reducing friction and hesitancy and getting more shots in arms.

• Do you have any plans to add capacity information to the slots? We try to prioritize locations with more availability in our search results when possible. USDR has also been working on analytics and decision-making tools for health officers with this data, and knowing the capacity of unavailable slots is super valuable when we can get it (so we can start to say something about how utilized various locations are).

• Finally, we were curious about situations where different chains/brands are at the same location. For example, the King Soopers with ID "62000019" and the Little Clinic with ID "06104" have the same address ("3100 S Sheridan Blvd, Denver, CO"), and looking at the King Soopers website, it seems like the Little Clinic is inside the King Soopers. I would have expected them to have the same availability (or one to have availability listed and the other none), but they have different availability. For example, reading both of these from the same request:

Rob Brackett (May 28 2021 at 16:21):

Also, as a more basic question: roughly how frequently are you refreshing/how frequently can I call the API? The response’s access-control-max-age header is set to 3628800 (42 days)!

Patrick Stuart (May 28 2021 at 17:37):

Is the $ in $bulk-publish only recommended or is it required? We have some concerns about compatibility when propagating the character through our network layers.

Josh Mandel (May 28 2021 at 19:32):

Required.

Josh Mandel (May 28 2021 at 19:32):

(It's a FHIR operation convention.)

Josh Mandel (May 28 2021 at 19:33):

Would be good to understand if there are specific software tools known to choke on this, though. We haven't heard reports of this.

Ryan Owens (Jun 01 2021 at 12:57):

@Rob Brackett Sorry for the delay - I took a few days off. Regarding your questions on content (product and capacity), those were questions which we debated with our product team extensively and our business and product teams did not want to expose that information through an API. Their decision was that if customers wanted that level of data, they needed to get it through our web properties. I will pass your comments along to our product team, but at this time I do not know of any plans to expand the data we are providing.

To your third question, our pharmacies and TLC clinics maintain separate inventory so it is very possible that a pharmacy may have product and a TLC clinic at the same location may not or vice versa. They operate largely as two separate businesses. They do not share inventory as far as I'm aware.

For frequency, I think we are currently updating the data every 15 or 30 minutes but that is temporary. Over the next several weeks we will be moving to more of an event driven model. It sounds like the header is messed up, so I'll follow up with the team to find out what's going on there. My guess is that it's related to a default value being added by a team up the chain from our dev team, but I'm not sure. Thanks for the info.

Rob Brackett (Jun 01 2021 at 15:38):

on content (product and capacity)… our business and product teams did not want to expose that information through an API. Their decision was that if customers wanted that level of data, they needed to get it through our web properties.

OK. FWIW, having this kind of data (including busy capacity) would be extremely helpful for us both in resident facing tools (product is the biggest deal here) and in decision-making tools/analysis for states.

Rob Brackett (Jun 01 2021 at 15:39):

our pharmacies and TLC clinics maintain separate inventory so it is very possible that a pharmacy may have product and a TLC clinic at the same location may not or vice versa.

Ah, thanks for the clarification. I had foolishly assumed that, where a TLC was embedded in and listed as a service of another store, it was functioning as the store’s pharmacy.

Ryan Owens (Jun 01 2021 at 19:28):

No, TLC's are healthcare clinics with Nurse Practitioners. They do not operate as pharmacies. Separate lines of business for us.

Hemanth Gorur (Jun 08 2021 at 20:11):

Hi , This is Hemanth from CastlightHealth . When we try accessing the Kroger fhir api, https://api.kroger.com/v1/health-wellness/schedules/vaccines/$bulk-publish we run into access token error. Can someone form Kroger help with removing the access token. The MVP appointment availability system is to integrate with fhir implementations that don't need authentication.

Hemanth Gorur: {
"error_description": "The access token is missing",
"error": "invalid_request"
}

Josh Mandel (Jun 08 2021 at 21:35):

@Hemanth Gorur you're describing the current scope of work for vaccines.gov?

Hemanth Gorur (Jun 08 2021 at 21:46):

Yes , I am describing the current state of work . I was wondering if the api, https://api.kroger.com/v1/health-wellness/schedules/vaccines/$bulk-publish can be made open ( without Authentication ) . This will help us surface Appointment Availability for Kroger in MVP.

Josh Mandel (Jun 08 2021 at 21:49):

@Ryan Owens I know this has come up before, and was out of scope initially; from the experience to-date, is there a chance to align Kroger's access policy with other pharmacies (CVS, Walgreens, and Rite-Aid)?

Ryan Owens (Jun 09 2021 at 12:08):

At this time, there has been no interest on our business team side to changing the authentication requirements. We knew this was going to be a consideration for some which is why we pushed to make sure the spec included support for OAuth, which I think it does (or at least it did when we started development). I have passed feedback like this along to our business leadership, but there has been no appetite so far to make any changes.

Rob Brackett (Jun 11 2021 at 05:20):

@Ryan Owens I was working with @Nick Muerdter tonight and we noticed an interesting discrepancy between the Kroger locations API and the SMART Scheduling links API — the locations with the IDs 85000898 and 85000899 are both marked as Frys Pharmacies in the SMART Scheduling links API, but the same IDs and addresses are shown as community clinics in the locations API (“Grace Methodist Church - Mesa” and “Dysart Community Center - El Mirage” respectively).

A quick check on Google Street View seems to indicate the non-Fry's names are correct, and I’m worried there might be a more widespread issue with the locations in the SMART Scheduling Links API. Do you have any insight as to what might be happening here?

Ryan Owens (Jun 11 2021 at 12:45):

Hmmm... I have a theory about why this would be, but I'll have to pass this along to the dev team to have them take a look. I suspect it has to do with how we internally handle temporary clinic locations. Thanks for letting us know.

Rob Brackett (Jun 11 2021 at 13:11):

No problem! Thanks for providing a good channel for feedback. :smile:

Ryan Owens (Jul 23 2021 at 21:17):

As of this afternoon, Kroger has removed the authentication requirement for our vaccine appoint availability API endpoint. Consumers should be able to access it now without a token.

Josh Mandel (Jul 23 2021 at 21:24):

Amazing!! Thanks for the update and the leadership on this @Ryan Owens.

Dennis Ai (Aug 11 2021 at 14:30):

Hi @Ryan Owens we noticed that the published data is 2021-08-11T00:38:40+00:00, which is not aligned with the format in spec 2021-08-11T03:46:20.534Z

Dennis Ai (Aug 11 2021 at 14:30):

Is that something you could take a look at?

Josh Mandel (Aug 11 2021 at 15:04):

Both of the examples you wrote here @Dennis Ai look like valid ISO 8601 dates to me.

Josh Mandel (Aug 11 2021 at 15:07):

Are you using a standard parser that is choking on one of these? The constraints on the fhir instant data type are that it needs to be at least to the one second precision, and then it must include a time zone specifier. Both of the examples here seem to meet both of those requirements.

Josh Mandel (Aug 11 2021 at 15:08):

http://hl7.org/fhir/datatypes.html#instant

Ryan Owens (Aug 11 2021 at 15:09):

I would agree with Josh. The spec specifically says ISO8601, with which our data appears to be compliant. While I also agree that the examples in the spec use the "Z" notation, those are just examples and not the actual spec.

Hemanth Gorur (Aug 17 2021 at 19:27):

We will evaluate the data and start the integration.

Hemanth Gorur (Aug 23 2021 at 22:07):

We are close to pushing the Kroger appointment availability to production. We are matching on the store id ( location Id ).

However I want to report what we found after analyzing the Appointment data published on https://api.kroger.com/v1/health-wellness/schedules/vaccines/$bulk-publish.

The value for https://cdc.gov/vaccines/programs/vtrcks is repeated. Here are some examples of it.

{"resourceType":"Location","id":"70300108","identifier":[{"system":"https://cdc.gov/vaccines/programs/vtrcks","value":"40173619"}],"name":"Ralphs Pharmacy #70300108","telecom":[{"system":"phone","value":"8585971550"},{"system":"url","value":"https://www.ralphs.com/rx/landing-page"}],"address":{"line":["8657 Villa La Jolla Dr"],"city":"La Jolla","state":"CA","postalCode":"92037"}}
{"resourceType":"Location","id":"03108","identifier":[{"system":"https://cdc.gov/vaccines/programs/vtrcks","value":"40173619"}],"name":"The Little Clinic #03108","telecom":[{"system":"phone","value":"6026802386"},{"system":"url","value":"https://www.thelittleclinic.com"}],"address":{"line":["2727 W Bell Rd"],"city":"Phoenix","state":"AZ","postalCode":"85053"}}
{"resourceType":"Location","id":"03111","identifier":[{"system":"https://cdc.gov/vaccines/programs/vtrcks","value":"40173621"}],"name":"The Little Clinic #03111","telecom":[{"system":"phone","value":"4803396178"},{"system":"url","value":"https://www.thelittleclinic.com"}],"address":{"line":["1935 N Stapley Dr"],"city":"Mesa","state":"AZ","postalCode":"85203"}}
{"resourceType":"Location","id":"70300111","identifier":[{"system":"https://cdc.gov/vaccines/programs/vtrcks","value":"40173621"}],"name":"Ralphs Pharmacy #70300111","telecom":[{"system":"phone","value":"3105389008"},{"system":"url","value":"https://www.ralphs.com/rx/landing-page"}],"address":{"line":["2201 W Redondo Beach Blvd"],"city":"Gardena","state":"CA","postalCode":"90247"}}
{"resourceType":"Location","id":"03113","identifier":[{"system":"https://cdc.gov/vaccines/programs/vtrcks","value":"40173622"}],"name":"The Little Clinic #03113","telecom":[{"system":"phone","value":"4808092409"},{"system":"url","value":"https://www.thelittleclinic.com"}],"address":{"line":["6470 S Higley Rd"],"city":"Gilbert","state":"AZ","postalCode":"85298"}}
{"resourceType":"Location","id":"70300113","identifier":[{"system":"https://cdc.gov/vaccines/programs/vtrcks","value":"40173622"}],"name":"Ralphs Pharmacy #70300113","telecom":[{"system":"phone","value":"9093571380"},{"system":"url","value":"https://www.ralphs.com/rx/landing-page"}],"address":{"line":["16225 Sierra Lakes Pkwy"],"city":"Fontana","state":"CA","postalCode":"92336"}}

Dennis Ai (Aug 23 2021 at 22:42):

Hi @Ryan Owens we noticed that the data is only being updated every few days

Dennis Ai (Aug 23 2021 at 22:43):

Can you give us a better understanding of how often the data is refreshed? I was under the impression that it was every 15 or 30 minutes

Ryan Owens (Aug 24 2021 at 20:51):

@Dennis Ai The team is investigating, but what specifically leads you to think it is only refreshed every few days? Is it a timestamp? Or are you just not seeing changes? If it's the latter, that may be entirely correct. Our stores open up additional appointments periodically (every few days sounds believable) and I don't think demand is high enough right now for most of our sites to have status changes from available to unavailable, so you may only see data changes every few days even though we are refreshing much more often. On the other hand, if you aren't seeing a timestamp update, then that's another matter.

Mike Maass (Aug 26 2021 at 20:03):

Hopefully I'm able to clarify a few things here in-regards to the data currently being published.

1. We have verified there is an issue with the vtrcks pin for several locations and we are currently working on a resolution that we hope to have released in the near future.

2. As far as the data refresh interval we are currently updating our availability using a batch process that runs every 30 minutes but in the near future will be moving to an event based model where the availability data will be updated every 5 minutes. With that being said since we are only reporting whether a location has availability (free) or has no availability (Busy) and not specifically on the individual timeslots at the locations. In addition we only update the FHIR files (slot files) when the availability changes for a location within said file. As a result the timestamp on many of the files may only get updated a couple times a day.

Josh Mandel (Aug 26 2021 at 20:21):

If I'm understanding correctly, the timestamp on the manifest should still always be correct (and less than 30 minutes old, and soon to be less than 5 minutes old), even if the manifest is pointing to (some) files that have not changed recently

Ryan Owens (Aug 26 2021 at 20:41):

@Mike Maass Can you follow up on Josh's question?

Mike Maass (Aug 27 2021 at 13:50):

@Josh Mandel We missed updating the timestamp on the manifest file when incremental updates are being done. We have a planned release next week and we add a fix for the timestamp in the upcoming release.

Rob Brackett (Oct 22 2021 at 21:56):

@Ryan Owens I was recently cleaning up some of our stuff, and noticed several places where there are >2 locations with the same name at the same address in Kroger's API. I think we talked earlier about a different pharmacy sometimes being embedded within a Grocery store, so I wasn’t suprised to see a "Kroger Pharmacy" at the same address as a "Ralphs." However, here's one with three Kroger Pharmacies at the same address as Ralphs!

curl "https://api.kroger.com/v1/health-wellness/schedules/vaccines/locations.ndjson" | grep -i '260 S La Brea' | jq

I saw more like this, but haven't had a chance to make an exhaustive search. Do you know if this is correct?

Ryan Owens (Oct 25 2021 at 13:51):

@Rob Brackett I'll pass this on to the support team. Just to be clear, we would only ever have one pharmacy at a given location. I think what you're referring to as a "different pharmacy" is not actually a pharmacy but rather one of our "The Little Clinic" locations, our nurse practitioner clinics. They also give vaccines but operate as a different business unit, but they are not pharmacies - they are more like medical practices than pharmacies. We do provide their data though as part of our feed. Having said that though, I don't know that we have any TLC locations in Ralph's (don't quote me on that though) and I think the name in the record would state that it is a TLC location if that were the case. My best guess is that this pharmacy likely operated some off-site pop-up clinics and somehow that's throwing things off. I'll have to wait for the team to investigate.

Ryan Owens (Oct 25 2021 at 13:52):

@Kyle Boroff leads the team that will be investigating.

Kyle Boroff (Oct 25 2021 at 14:22):

@Rob Brackett We identified the issue. The multiple extra pharmacies were inactive 'associate only' pop up locations tied to that store. We have a bug where we are not filtering out these inactive locations. I am working with the team now to work on the fix and can keep you updated.

Rob Brackett (Oct 25 2021 at 16:13):

@Ryan Owens @Kyle Boroff thanks for looking into it! FWIW, I just ran a quick check to find situations where there were multiple locations at the same address, and where the names weren't just "The Little Clinic" and one other. There are quite a reasonable number:

• multiple-kroger-locations-by-address.txt
• multiple-kroger-locations-more-than-two-tlcs.txt

Examples from the above files:

31 Sherwood Blvd, 87547
  Smith's Pharmacy #70600432
  Kroger Pharmacy #43992
  Dillons Pharmacy #85000992
  Kroger Pharmacy #70609

535 E Palmer Wasilla Hwy, 99645
  Fred Meyer Pharmacy #70100649
  Fred Meyer Pharmacy #70100669

Rob Brackett (Oct 25 2021 at 16:18):

I also get the impression from looking at the data that the first 2 or 3 digits of the 8 digit IDs (which not all locations use) are some kind of meaningful prefix (although some names cross multiple prefixes), and that 85* might be some kind of ad hoc or community clinics. Is that right?

Rob Brackett (Oct 25 2021 at 16:20):

In particular, we have some older records of places with those IDs having different names (which we wind up keeping, based on how the system works), and I never noticed that some of them changed to a more generic "The Little Clinic #xyz", for example. (See this earlier discussion: https://chat.fhir.org/#narrow/stream/281612-smart.2Fscheduling-links/topic/Publisher.3A.20Kroger/near/242302308)

Rob Brackett (Oct 25 2021 at 16:22):

Finally, we have 8-digit IDs for all The Little Clinics from an older(?) system that I realized we were duplicating because The Little Clinics in the SMART Scheduling Links API only have 5 digits. It seems like there’s a clean mapping, though (which harkens back to the question about prefixes above). Is this getting at something more meaningful about the types of locations under the hood?

For example, if the SMART SL has a The Little Clinic with the ID 03102, its 8-digit ID is 85100102.

Ryan Owens (Oct 25 2021 at 16:39):

I can't fill in all of the gaps here but our normal numbering system is a 3 digit division followed by a 5 digit store number. So for example, our "Mid Atlantic" division is 029, Nashville is 026, etc. Store number usually start with 00 followed by three digits. If you use www.kroger.com store locator and pay attention to the URLs, you'll be able to see this pattern I believe (based on memory - could be wrong). Where it gets weird is the pop-up clinics and things of that nature. They tend to use made up store numbers for those in ranges they know will not collide with real stores. They (our business team) may use various patterns for this that Kroger Technology is not necessarily aware of. So all I personally can tell you for certain is that our real store locations will have eight digit (3 + 5) IDs. Anything else is probably something special (but an eight digit ID by itself doesn't necessarily mean it's automatically a real store).

Rob Brackett (Oct 25 2021 at 16:43):

Oh, fascinating! Thanks for filling that in.

Rob Brackett (Oct 25 2021 at 21:01):

@Ryan Owens I’m also now noticing that there are currently 610 schedules that reference locations that don’t exist… is that many expected? I think I’d noticed this before but assumed they might not always perfectly match a while back when you mentioned switching to a more evented model. This seems like a lot, though.

Alex Olear (Oct 25 2021 at 21:32):

@Rob Brackett @Ryan Owens I saw Rob's message and was curious about the number as well. I think I know what the issue is and I'll forward along to the team

Last updated: Apr 12 2022 at 19:14 UTC