Stream: smart/scheduling-links
Topic: Publisher: Rite-Aid
Patrick Stuart (Jun 01 2021 at 22:29):
Josh Mandel said:
Would be good to understand if there are specific software tools known to choke on this, though. We haven't heard reports of this.
Insomnia is URL-encoding the character which confuses our server. Capture.PNG
Josh Mandel (Jun 02 2021 at 02:43):
Huh, those URLs ($ and %24) should be semantically equivalent, meaning that both should work. What Web server are you using that's differentiating between them?
Patrick Stuart (Jun 02 2021 at 16:53):
I don't feel comfortable sharing our internal frameworks.
I can say I posted this request through two layers on two entirely different frameworks. It got stuck on both of them.
Josh Mandel (Jun 02 2021 at 17:24):
Huh. It looks like the riteaid's server performs correct decoding for other characters, e.g.
GET /digital/vaccine-provider/$%62ulk-publish
works, with b encoded a %62. The issue appears to be specific to decoding %24.
Rob Brackett (Jun 02 2021 at 20:59):
Oh, interesting. We’re using Express (JavaScript) and it looks like it has a similar bug: http://getmyvax.org/smart-scheduling/%24bulk-publish
Will have to fix.
Josh Mandel (Jun 02 2021 at 22:08):
@Patrick Stuart bottom line I wouldn't get stuck on this point -- if you need to host the manifest at /bulk-publish to keep going, I'd say just keep going and we can revisit this later.
Patrick Stuart (Jun 03 2021 at 15:07):
@Josh Mandel unless I'm calling it wrong, the InfernoTest tool appears to be stuck... image.png
Josh Mandel (Jun 03 2021 at 16:03):
@Robert Scanlon are there logs available? It it possible Inferno is crashing with something specific to the Rite-Aid endpoint?
Robert Scanlon (Jun 03 2021 at 17:58):
Looking through the logs now. Looks like the server failed a test, then Inferno's test runner crashed when trying to persist the failure message. We recently swapped the ORM we are using, which may have something to do with the crash.
Robert Scanlon (Jun 03 2021 at 18:00):
While we figure out why Inferno crashed, it looks like the server doesn't like the accept header we are sending?
ERROR | Inferno | Fatal Error: 784: unexpected token at '<!doctype html><html lang="en"><head><title>HTTP Status 406 – Not Acceptable</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 406 – Not Acceptable</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> Not Acceptable</p><p><b>Description</b> The target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request, and the server is unwilling to supply a default representation.</p><hr class="line" /><h3>Apache Tomcat/9.0.36</h3></body></html>'
Robert Scanlon (Jun 03 2021 at 18:01):
I believe we are sending 'Accept: application/fhir+ndjson'
Josh Mandel (Jun 03 2021 at 19:01):
Cool. This is the first time we're seeing an issue here, but we should probably add to the spec something like:
- Servers SHALL support
Accept: application/fhir+ndjson - Servers SHALL support
Accept: application/x-ndjson(??) - Servers SHALL support requests without an
Acceptheader
Josh Mandel (Jun 03 2021 at 19:01):
@Patrick Stuart does this give you enough to get un-stuck?
Robert Scanlon (Jun 03 2021 at 19:20):
I think that would be a good idea, even if it feels a bit tedious to be explicit about this kind of detail. I wouldn't want to have to configure the client which Accept to use on an endpoint-to-endpoint basis.
Robert Scanlon (Jun 03 2021 at 19:22):
Also, slightly related, I noticed the content-type header returned from $bulk-publish in this server is 'application/x-ndjson' which is technically incorrect (I think?), though we do not check that in our tests. I suppose we could flag a warning.
Josh Mandel (Jun 03 2021 at 20:32):
Warning seems OK on the output. I'll add a PR to include these details.
Josh Mandel (Jun 03 2021 at 20:40):
Added https://github.com/smart-on-fhir/smart-scheduling-links/pull/43
Patrick Stuart (Jun 03 2021 at 21:21):
Thank you! I'll take a look at what might be causing this issue.
Robert Scanlon (Jun 04 2021 at 14:17):
@Josh Mandel did you include application/fhir+json as an option for the Accept header for the bulk manifest file because the bulk manifest file qualifies as application/fhir+json, or simply to make things a little easier for clients? I assumed that application/fhir+json was only for FHIR resources, which this is not. No objection either way, just curious.
Josh Mandel (Jun 04 2021 at 15:30):
You're right @Robert Scanlon -- I'll fix this by deleting that bullet.
Josh Mandel (Jun 04 2021 at 15:31):
Ashwath Ramesh (Jun 06 2021 at 08:54):
Josh Mandel said:
Cool. This is the first time we're seeing an issue here, but we should probably add to the spec something like:
- Servers SHALL support
Accept: application/fhir+ndjson- Servers SHALL support
Accept: application/x-ndjson(??)- Servers SHALL support requests without an
Acceptheader
Hi Josh,
Even after setting the header as application/fhir+ndjson it is failing inferno tests can you let me know what exactly I need to pass in header. to pass this test case.
image.png
Josh Mandel (Jun 06 2021 at 12:36):
Just to check, did you review the updated spec section at https://github.com/smart-on-fhir/smart-scheduling-links/blob/master/specification.md#accept-headers, and can you include the rest of the logs here @Ashwath Ramesh ? The result in your screenshot is cut off z so maybe you can copy snd paste the text?
Or perhaps @Robert Scanlon can check on the Inferno server side?
Robert Scanlon (Jun 06 2021 at 16:18):
@Ashwath Ramesh Could you confirm that you do not reject requests to Bulk Download Files (e.g. PA.ndjson) that have the Accept header of Accept: application/fhir+ndjson. I'm still seeing the following response in our logs when trying to access those URLs:
Robert Scanlon (Jun 06 2021 at 16:19):
<!doctype html><html lang="en"><head><title>HTTP Status 406 – Not Acceptable</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 406 – Not Acceptable</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> Not Acceptable</p><p><b>Description</b> The target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request, and the server is unwilling to supply a default representation.</p><hr class="line" /><h3>Apache Tomcat/9.0.36</h3></body></html>
Robert Scanlon (Jun 06 2021 at 16:26):
e.g. curl https://apicar.riteaid.com/digital/vaccine-provider/states/locations/PA.ndjson -H "Accept: application/fhir+ndjson"
Patrick Stuart (Jun 06 2021 at 23:54):
Thanks for the help, team! This was a deployment issue on our end... nothing further for you guys to handle for now.
Ashwath Ramesh (Jun 07 2021 at 15:40):
all the tests are passed except these two image.png
image.png am passing the below fields for servicetype in schedules "serviceType": [
{
"coding": [
{
"system": "https://www.riteaid.com/covid-19",
"code": "covid19vaccine",
"display": "COVID-19 Immunization Appointment"
}
]
}
],
I dont know why its failing and in slots am passing store number as part of reference image.png
"schedule": {
"reference": "Schedule/5644"
},
Josh Mandel (Jun 07 2021 at 15:44):
The example you pasted above @Ashwath Ramesh is missing a coding -- if you want to advertise covid-19 immunization appointments, then serviceType should look like:
json
see https://github.com/smart-on-fhir/smart-scheduling-links/blob/master/specification.md#schedule-file for details
Ashwath Ramesh (Jun 07 2021 at 16:40):
image.png
"serviceType": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/service-type",
"code": "5426",
"display": "Immunization"
},
{
"system": "http://fhir-registry.smarthealthit.org/CodeSystem/service-type",
"code": "covid19-immunization",
"display": "COVID-19 Immunization Appointment"
}
]
}
],
Am passing whatever you suggested but still test cases are not getting passed. image.png
Josh Mandel (Jun 07 2021 at 18:45):
The Coding your showed here (code 5426) doesn't match the required coding (code 57)
Ashwath Ramesh (Jun 08 2021 at 06:20):
thanks Josh coding is fixed but last test case is failing am setting schedule in slots service as per the sample file but it is failing:
image.png
image.png
image.png
image.png slot
Can it be a store number or store id?
Josh Mandel (Jun 08 2021 at 13:26):
The format for an ID is opaque; it's any string consisting of letters and numbers that is less than 64 characters long (see spec for details).
Josh Mandel (Jun 08 2021 at 13:28):
The screenshots you are showing from the validator indicate that the validator is seeing a reference to Schedule/13 from an appointment slot, but that no Schedule with id 13 is findable from your manifest. (And apparently this is an issue for a couple of dozen IDs.)
Ashwath Ramesh (Jun 08 2021 at 13:59):
Hi Josh,
PFB the latest screenshots am passing the same id which I pass in schedule, in slot's reference, but its failing,
image.png
image.png
image.png
Robert Scanlon (Jun 08 2021 at 14:04):
The Slot is given a reference to a Schedule with an ID of 5617. The Schedule resource you are showing there has an id of Schedule5617, not 5617. You can either change the Slot to reference Schedule/Schedule5617 or change the Schedule to have an ID of 5617.
Robert Scanlon (Jun 08 2021 at 14:10):
Note that when one resource references another, the reference is in the form {ResourceType}/{id}. So when the Slot references Schedule/5617, that means there needs to be a Schedule resource with an ID of 5617.
Josh Mandel (Jun 08 2021 at 14:14):
This is spelled out explicitly at https://github.com/smart-on-fhir/smart-scheduling-links/blob/master/specification.md#schedule-file -- it is worth reading through the doc top to bottom in case there are other issues you may have missed as well
Ashwath Ramesh (Jun 08 2021 at 14:15):
image.png all the tests have passed thanks Josh and Robert for answering my questions
Patrick Stuart (Jun 09 2021 at 03:06):
FYI we are still on schedule for deployment Thursday.
Patrick Stuart (Jun 10 2021 at 15:27):
Ashwath Ramesh said:
Hi Josh, The deployment is done in production it will be helpful if you could please validate the services now and approve the pull request and merge it to the publisher repository. image.png image.png
I don't think we need Josh to verify anything.
Josh Mandel (Jun 10 2021 at 16:22):
Great! I merged the PR last week, but placed the metadata files In an "awaiting validation" folder. It's now in the main folder at https://github.com/smart-on-fhir/smart-scheduling-links/blob/master/publisher-repository/riteaid.json -- let me know if anything looks off!
Hemanth Gorur (Jun 10 2021 at 21:44):
Hi I am from Castlight , we have been trying to use the RiteAid Fhir API to get appointment availability. Since VTrckS PINs were not part of the payload for uniquely identifying a location, we tried using Store Id. The two fields labeled ID is either black or populated with zip code. @Patrick Stuart had indicated that the Fhir API's have some bugs. Just wanted to check if this will be addressed in the Thursday release.
Josh Mandel (Jun 10 2021 at 21:48):
For the Rite-Aid team @Patrick Stuart , the preferred approach here is to populate Location.identifier with an entry like:
"identifier": [{
"system": "https://locations.riteaid.com",
"value": "10209"
}]
(for store #10209; this is totally independent of how you populate Location.id, since the semantics of Location.id are opaque to clients.)
Josh Mandel (Jun 10 2021 at 21:51):
It also looks like the current endpoint only provides appointment availability for today -- is there a plan to publish for 1-2 weeks out?
Ashwath Ramesh (Jun 11 2021 at 02:40):
@Josh Mandel sure Josh will set store id in location identifier value, currently we are setting the zip code. Will discuss with Patrick and finalize for displaying appointments availability for 1-2 weeks.
Rob Brackett (Jun 11 2021 at 05:28):
Is https://api.riteaid.com/digital/vaccine-provider/$bulk-publish still the right URL? Taking a look at it now, I’m seeing all the schedules with malformed vaccine-product extensions:
{
"extension": [
{
"url": "http://fhir-registry.smarthealthit.org/StructureDefinition/vaccine-dose",
"valueInteger": 1
},
{
"url": "http://fhir-registry.smarthealthit.org/StructureDefinition/vaccine-product",
"valueCoding": {
"system": "http://terminology.hl7.org/CodeSystem/service-type",
"code": "57",
"display": "Immunization"
}
}
]
}
^ The dose extension is fine, but product is clearly one of the codings from the service type, which is way off spec. (Maybe Inferno is not validating these extensions?)
Josh Mandel (Jun 11 2021 at 13:08):
Looks like a bug. This might be worth addressing in the validator (presence of a CVC code on vaccine product extensions) @Robert Scanlon
Robert Scanlon (Jun 11 2021 at 13:31):
Hmm, we'll take a look. FYI @Michael O'Keefe
Robert Scanlon (Jun 11 2021 at 14:55):
@Michael O'Keefe it looks like that coding is bound to http://hl7.org/fhir/uv/smarthealthcards-vaccination/ValueSet/vaccination-credential-vaccine-value-set, which we aren't providing, and I'm not seeing how the validator would know where to find it (presumably in the HealthCards/VCI IG, or something like that?). I don't know if this is what is causing this issue or not, but regardless I wonder if it makes sense to have this "IG" depend on that IG. Would it make more sense to bind to http://hl7.org/fhir/ValueSet/vaccine-code (which is more than just CVX, but I'm not sure if that matters), or create our own ValueSet that just wraps CVX?
Michael O'Keefe (Jun 14 2021 at 13:40):
In theory that valueset should be validated through tx.fhir.org. I believe the VCI/SMART Health Cards team said they were able to get that valueset added to tx.fhir.org; not sure why it wouldn't be resolving
Robert Scanlon (Jun 14 2021 at 14:53):
It looks like that ValueSet doesn't exist any more in the IG (looks like they renamed it here).
Robert Scanlon (Jun 14 2021 at 14:55):
And I can't find the replacement on tx.fhir.org (not 100% sure this is the right query though).
Robert Scanlon (Jun 14 2021 at 15:00):
Does tx.fhir.org keep ValueSets around after restarts? Regardless, I think having a dependency on such an actively developed IG for such a small thing is probably not a good idea and may result in us under-validating without realizing it (as happened here).
Michael O'Keefe (Jun 14 2021 at 15:13):
I suppose. I really don't like the idea of creating a second, mostly-identical valueset, if one already exists, but if it's what people want to do.
Ashwath Ramesh (Jun 16 2021 at 17:02):
Hi Josh
we have deployed the fix to display slots for seven days in dev environment. It passed all the inferno test image.png . please let me know whether it is looking good. PFB url : Inferno Logo Small https://apidev.riteaid.com/digital/vaccine-provider/$bulk-publish
Josh Mandel (Jun 16 2021 at 18:25):
Thanks -- confirmed I'm seeing seven days of results in the Slot files
Yijie Hong (Jun 21 2021 at 16:31):
In https://api.riteaid.com/digital/vaccine-provider/$bulk-publish, "transactionTime" is given in format of "yyyy-MM-dd HH:mm", e.g. "2021-06-18 21:04". I am curious about time zone. It is EST?
Patrick Stuart (Jun 21 2021 at 19:21):
Yijie Hong said:
In https://api.riteaid.com/digital/vaccine-provider/$bulk-publish, "transactionTime" is given in format of "yyyy-MM-dd HH:mm", e.g. "2021-06-18 21:04". I am curious about time zone. It is EST?
Yep it's in EST.
Patrick Stuart (Jun 21 2021 at 19:24):
Latest release is published.
Change log:
- VTRKs PIN added
- Endpoint is 14 days out, not 1.
- Slot ndjson files have valid extensions
- Properly formed vaccine-product extensions
Yijie Hong (Jun 22 2021 at 00:12):
Patrick Stuart said:
Latest release is published.
Change log:
- VTRKs PIN added
- Endpoint is 14 days out, not 1.
- Slot ndjson files have valid extensions
- Properly formed vaccine-product extensions
Thanks!
Rob Brackett (Jun 22 2021 at 17:44):
Just took a look at this and noticed that address.district in the locations is the name of the city, not the county. (Turns out that’s also the case in the the internal API, so I’ve got a lot of Rite Aid locations to go find the actual county for and fix…)
Rob Brackett (Jun 22 2021 at 17:47):
Seems like the URL that should be in telecom is set as the location's description, too. For example, here's one from Deleware:
{
"resourceType": "Location",
"id": "129",
"telecom": [
{
"system": "phone",
"value": "(302) 368-1614"
}
],
"description": "https://www.riteaid.com/covid-19",
// ...other properties here...
}
Rob Brackett (Jun 22 2021 at 17:58):
Also just noticed that, in the manifest, State is capitalized when it should not be:
{
"type": "Slot",
"url": "https://api.riteaid.com/digital/vaccine-provider/states/slots/DE.ndjson",
"extension": {
"State": [
"DE"
]
}
},
The validator isn’t erroring on it because it’s just seeing it as an unknown, extra extension, but you can see that it’s not seeing it as the state extension:
Screen-Shot-2021-06-22-at-10.58.02-AM.png
Patrick Stuart (Jun 22 2021 at 19:39):
Yijie Hong said:
Patrick Stuart said:
Latest release is published.
Change log:
- VTRKs PIN added
- Endpoint is 14 days out, not 1.
- Slot ndjson files have valid extensions
- Properly formed vaccine-product extensions
Thanks!
@Yijie Hong we can fix this in an upcoming release to use UTC.
Patrick Stuart (Jun 22 2021 at 19:43):
Rob Brackett said:
Just took a look at this and noticed that
address.districtin the locations is the name of the city, not the county. (Turns out that’s also the case in the the internal API, so I’ve got a lot of Rite Aid locations to go find the actual county for and fix…)
Rob Brackett said:
Seems like the URL that should be in
telecomis set as the location's description, too. For example, here's one from Deleware:{ "resourceType": "Location", "id": "129", "telecom": [ { "system": "phone", "value": "(302) 368-1614" } ], "description": "https://www.riteaid.com/covid-19", // ...other properties here... }
Rob Brackett said:
Also just noticed that, in the manifest,
Stateis capitalized when it should not be:{ "type": "Slot", "url": "https://api.riteaid.com/digital/vaccine-provider/states/slots/DE.ndjson", "extension": { "State": [ "DE" ] } },The validator isn’t erroring on it because it’s just seeing it as an unknown, extra extension, but you can see that it’s not seeing it as the state extension:
Screen-Shot-2021-06-22-at-10.58.02-AM.png
@Rob Brackett we will fix these in an upcoming release. Can you check to ensure you aren't seeing any other issues, please? Each of these changes has to go through QA.
Rob Brackett (Jun 22 2021 at 19:55):
I noticed Slots that are free seem to have narrower hours that might be meaningful:
{
"status": "free",
"start": "2021-06-26T09:00:00Z",
"end": "2021-06-26T18:00:00Z",
}
But busy slots are all day:
{
"status": "busy",
"start": "2021-06-27T00:00:00Z",
"end": "2021-06-27T23:59:59.999999999Z",
}
Wondering if I can or should infer something like business hours from the free times (although it looks like maybe the timezone offset is wrong — those examples were from California, so the timeframe for that slot is 2am–11am local time).
Rob Brackett (Jun 22 2021 at 19:56):
I don’t see any other obvious technical issues besides the ones I and others already noted, though! :thumbs_up:
Josh Mandel (Jun 22 2021 at 20:09):
Yijie Hong said:
In https://api.riteaid.com/digital/vaccine-provider/$bulk-publish, "transactionTime" is given in format of "yyyy-MM-dd HH:mm", e.g. "2021-06-18 21:04". I am curious about time zone. It is EST?
Just to note, this isn't a valid timestamp; it should have a T before the time, and an offset specifier at the end. @Robert Scanlon is there an opportunity to validate these?
Rob Brackett (Jun 22 2021 at 20:12):
See also:
- https://chat.fhir.org/#narrow/stream/281612-smart.2Fscheduling-links/topic/Consumer.3A.20MITRE.20.2F.20Inferno.20Tests/near/243555366 and
- https://github.com/smart-on-fhir/smart-scheduling-links/pull/48
:grinning_face_with_smiling_eyes:
Josh Mandel (Jun 22 2021 at 20:18):
Thanks Rob (and just merged your PR)
Patrick Stuart (Jun 23 2021 at 02:48):
(redacted)
Patrick Stuart (Jun 23 2021 at 02:57):
(redacted)
Patrick Stuart (Jun 23 2021 at 16:50):
Good morning. I have a technical question on how we should indicate the free vs. busy slots.
It looks like our developer provided an aggregate slot capacity on the whole day and only provided free slots.
Is this acceptable or should we be listing each busy/free slot individually?
For what it's worth, this doesn't easily fit our paradigm as we occasionally have more slots available than actual vaccines to give. We close the remaining slots once the vaccines have hit a maximum number.
Josh Mandel (Jun 23 2021 at 16:58):
In general, we encourage publishing fine-grained slot information indicating specific times when appointments can be booked. If you can do this, it's preferred. If you have 1 dose of vaccines but 10 open time slots, it's okay to transition from 10 open slots to 0 open slots when that final dose is spoken for.
Josh Mandel (Jun 23 2021 at 17:00):
But when this happens, you shouldn't mark all 10 slots as busy -- one would become busy and 9 would disappear (no longer actually an appointment slot for this service; we could talk about other options for how to model this, too...)
Patrick Stuart (Jun 24 2021 at 00:19):
We have a release scheduled for tomorrow evening Eastern time.
Change log:
- Remove district (optional field that had an incorrect value)
- Added URL to Telecom
- Fixed capitalization on state
- Added correct time zone on slots
- Fixed transaction time format as well as added time zone
- FIxed location description
- Added consistent time reporting
Future changes:
- Listing slots individually. Currently it aggregates them over the day and doesn't report busy slots unless they're all used.
- Add county.
- Add a URL that will bring users to the qualifier for the store in question. Currently we use the same URL for every store.
A preview is here: https://apicar.riteaid.com/digital/vaccine-provider/$bulk-publish.
We would love and appreciate any feedback anyone has. Thank you.
Madhura Chinthala (Jun 24 2021 at 16:43):
Hi Josh, We fixed few issues in the apis But we are seeing different inferno test results in different environments. All test are passing in our Test env, But failing in QA. From the inferno error, I understand that it is expecting a value for description in location API, But according to the spec it should be a string. Could you please suggest what could be the issue here. Here is the link of the results.
https://infernotest.healthit.gov/community/9ECyD0BkVtz/test_sets/ad_hoc_testing/#SMARTSchedulingLinksSlotPublisherTests/ad_hoc_testing_SMARTSchedulingLinksSlotPublisherTests_SmartSchedulingLinksBasicSequence
Patrick Stuart (Jun 24 2021 at 17:07):
Ping @Rob Brackett who wrote the service.
Rob Brackett (Jun 24 2021 at 17:08):
Patrick Stuart said:
Ping Rob Brackett who wrote the service.
Oh, that’s not me! I believe you want @Robert Scanlon, but am not 100% sure on that.
Rob Brackett (Jun 24 2021 at 17:16):
That said, the error in that output looks accurate. There is at least one empty description (in PA). There should be a value or the property should simply not be present.
Here's what I did to quickly check that:
for STATE in DE OR WA NY VA PA CT MA MD OH NH ID MI NJ CA; do
echo "Checking $STATE"
http "https://apisqa.riteaid.com/digital/vaccine-provider/states/locations/${STATE}.ndjson" | jq .description
done
Rob Brackett (Jun 24 2021 at 17:17):
(That's bash, so you should be able to run it on a *nix/MacOS terminal or WSL on Windows)
Madhura Chinthala (Jun 24 2021 at 17:28):
Thanks for the quick response on this, we will fix that data, Along with this error, we are seeing a different error as below
"1167 unknown Locations referenced as actor (e.g. Location/4062)"
Could you please elaborate on that as well.
Patrick Stuart (Jun 24 2021 at 17:30):
@Rob Brackett thank you! In fact, it succeeded after we fixed the description issue. Seems it was a downstream failure.
Rob Brackett (Jun 24 2021 at 17:37):
Looking forward to seeing this ship tonight! :)
Two questions:
- Is the API reporting live results or, if not, at what rate is it updating? (Apologies if this was already stated somewhere and I just lost track)
- Do you have any future plans to include vaccine product info in the schedule endpoint?
Robert Scanlon (Jun 24 2021 at 18:05):
Sorry for not responding quicker here regarding the Inferno error messages. The results from that test session you linked above all now pass - I assume that’s because you were able to fix the issues Inferno was providing and reran the tests?
Madhura Chinthala (Jun 24 2021 at 18:07):
Yes, all tests are passing now after fixing the description.
Robert Scanlon (Jun 24 2021 at 18:08):
Josh Mandel said:
Yijie Hong said:
In https://api.riteaid.com/digital/vaccine-provider/$bulk-publish, "transactionTime" is given in format of "yyyy-MM-dd HH:mm", e.g. "2021-06-18 21:04". I am curious about time zone. It is EST?
Just to note, this isn't a valid timestamp; it should have a
Tbefore the time, and an offset specifier at the end. Robert Scanlon is there an opportunity to validate these?
Hmmm this is a surprising miss by the HL7 FHIR validator. We’ll look into it.
Josh Mandel (Jun 24 2021 at 20:48):
It's a field from http://hl7.org/fhir/async.html which kind of exists outside of the world of StructureDefinitions, so it's not quite an HL7 validation issue.
Robert Scanlon (Jun 24 2021 at 21:26):
Ah, didn't read that close enough, we could add that too
Hemanth Gorur (Jun 24 2021 at 21:54):
Castlight reviewed the store id published by Rite-Aid on FHIR API. The store ld is populated and we were able to match it with store id coming from CDC. Thank you.
Dennis Ai (Jul 02 2021 at 17:11):
Just a heads up RiteAid should now also be published on Google Search and Maps, thanks for everyone's work on this
Patrick Stuart (Jul 13 2021 at 12:26):
Patrick Stuart said:
Insomnia is URL-encoding the character which confuses our server. Capture.PNG
@Josh Mandel
FYI this is fixed in the latest version of Insomnia
Josh Mandel (Jul 13 2021 at 13:39):
Excellent!
Hemanth Gorur (Jul 14 2021 at 20:24):
Castlight integrated the Appointment availability data being shared by CVS, Rite-Aid and walgreens. Here is a demo of how the information will be presented on vaccines.gov https://vimeo.com/575047522/b7d63395d5 .
Patrick Stuart (Jul 24 2021 at 21:07):
@Rob Brackett our stores without availability are still being listed as unknown on vaccines.gov. Can you assist or point us in the relevant direction?
Rob Brackett (Jul 27 2021 at 22:01):
@Patrick Stuart I don't work directly on vaccines.gov (I’m with USDR, working with state govs and on getmyvax.org, as well as some community/grassroots groups), so @sophia golden, @Hemanth Gorur, or @Gavin Thompson are probably the people you want help from here.
Are you talking about the production vaccines.gov, or the in-development appointment stuff at dev.vaccinefinder.org? (I don't even have a login to view the latter.)
Rob Brackett (Nov 19 2021 at 05:43):
@Patrick Stuart both the old Rite Aid API that requires a key (https://api.riteaid.com/digital/Covid19-Vaccine/ProviderDetails) and the SMART Scheduling Links API (https://api.riteaid.com/digital/vaccine-provider/$bulk-publish) have been erroring for the last two days. Do you know what’s going on? These APIs are still a pretty big deal for our partners at the state of NJ, especially now that there’s a crunch for pediatric vaccines.
Rob Brackett (Nov 19 2021 at 05:44):
Requests to the API are currently returning:
{
"Data": null,
"Status": "ERROR",
"ErrCde": "RA0005",
"ErrMsg": "Something went wrong. Please contact Customer Care to continue.",
"ErrMsgDtl": null
}
Rob Brackett (Nov 22 2021 at 20:18):
@Patrick Stuart If you've at least got any background on what's going on, and if we and our state partners can expect a fix at some point (even if there's no timeframe yet), that would be super helpful.
Rob Brackett (Nov 29 2021 at 17:37):
@Patrick Stuart FYI, we’ve switched from the API to querying the same XHR endpoints used by the web-based booking flow, since this info was critical for our state partners. We’ll happily switch back to an API actually designed for public use whenever the issues are resolved, though.
Hemanth Gorur (Dec 07 2021 at 18:15):
@Patrick Stuart Are the Rite-Aid fhir api's back to working ?
Hemalatha Ravishankar (Feb 15 2022 at 21:21):
@Josh Mandel Do you have sample examples to include pediatrics vaccinations?
Last updated: Apr 12 2022 at 19:14 UTC
