Stream: smart/scheduling-links
Topic: VTrckS PINs
Josh Mandel (Apr 16 2021 at 18:46):
A requirement from the start has been identifying locations by their VTrckS PIN. In theory (see https://www.cdc.gov/vaccines/covid-19/reporting/vtrcks/index.html) any location administering vaccinations should have one, and this identifier is important for cross-referencing Slot data against datasets on vaccine availability. For folks on the Slot Publisher side: do you have these PINs in your database somewhere? (Or is there a different way that you support this cross-referencing?)
Cooper Thompson (Apr 16 2021 at 19:49):
Is there an assumption here that the scheduling system will have some insight into the vaccine allotment and storage systems? We built in a way for our health systems to specify an identifier on their schedulable locations, but I know we've had a lot of concerns with that being successful. I haven't fully grokked what exactly the VTrckS PIN represents. Is it something that has an obvious link to a schedulable location? I though it was more about allotment and maybe storage.
Josh Mandel (Apr 16 2021 at 19:51):
It's tied to locations, to the best of my understanding. I think the goal isn't that scheduling systems would deeply understand it but that a database of locations would include it, so tools like vaccine finder could join data across these modalities.
Cooper Thompson (Apr 16 2021 at 19:54):
Wouldn't it be possible for one schedulable location to administer vaccines from different lots associated with different PINs? Should we send multiple PINs per location? Or would we need to split out two location records for the same physical location if they admin from different allotments?
Josh Mandel (Apr 16 2021 at 19:58):
My understanding was that PINs correspond to locations, but my understanding is limited :-) Hoping someone here can share what they know.
Cooper Thompson (Apr 16 2021 at 20:01):
Right. But which location. The storage location or the schedulable admin location?
Cooper Thompson (Apr 16 2021 at 20:03):
For example, we had a vaccine clinic at Epic in one of our cafeterias. That is what would be scheduled. Would that have a VTrcksPIN assigned?
Josh Mandel (Apr 16 2021 at 20:19):
It could be many administration locations all using the same VTrcks PIN in that example.
Josh Mandel (Apr 16 2021 at 20:19):
But I'm not clear about whether anyone has experience working with these PINs
Cooper Thompson (Apr 16 2021 at 20:31):
I think it might be many-to-many. You could have many locations using the same PIN, but also one location using multiple PINs.
Josh Mandel (Apr 16 2021 at 21:51):
That's fair, and if this is the case it would be straightforward enough to list multiple instances of a pin on a single location. Any idea how we can get the answer to this question?
Ryan Owens (Apr 19 2021 at 12:47):
Our team was building off of the pre-4/6 spec and believed that VTrckS PIN was optional (per the spec from before April 6th). Our complexity is that our scheduling system does not have the VTrckS PIN information. We have two separate lines of business that administer vaccines (our pharmacies and our health clinics). For one of our lines of business, we do have a backend system that has the VTrckS PIN but we would prefer to not have to integrate this solution with that system. For our other line of business, the backend is a SaaS solution and we do not have access to pull VTrckS PIN data from that system at this time. We also had concerns about limited value in the data for the reasons discussed above (we will have multiple locations sharing VTrckS PINs). For all of those reasons and to avoid adding delays to deployment, our team decided to not include VTrckS PIN data in our initial release and to come back later and consider adding it. I will go back to the team with the updated spec and see what they think, but requiring VTrckS PINs may delay our ability to provide data.
Cooper Thompson (Apr 19 2021 at 13:54):
Ah - I didn't see the commit that made the VTRckS PIN required. If "required" means "must-support" (using US Core definition), then I guess we are compliant, but if it means 1..1, then we aren't (and won't be).
Josh Mandel (Apr 19 2021 at 14:15):
At this stage I would interpret it as "we've heard the US digital Services team say this field is critical, and we want to push to understand any concerns about what it would take to supply."
Josh Mandel (Apr 19 2021 at 14:16):
So far I think we are hearing that it may be many to one with locations, and possibly many to many. It's not yet clear to me how we determine which of these the case.
Nell Lapres (Apr 19 2021 at 14:21):
Our understanding is that the VTrcks Pin is assigned based on information from the IIS and how they onboard departments. For example, we heard from WIR (Wisconsin’s immunization registry) that they assigned their internal WIR pins based on where the vaccine is stored, not administered. While this example was for WI, we have heard that the specific onboarding process varies state by state. We are not confident that the VTrcks Pin will accurately represent a location where a patient is scheduled, which means it could not effectively be used for this use case.
Josh Mandel (Apr 19 2021 at 14:25):
the context here is very helpful. I'm not sure I understand the conclusion. If the association between administering sites and storage locations is many to one as you are describing, they can still be correlated and it might be possible to know that the storage facility associated with a given administration site does not have supply (through external stock data sources).
Michael O'Keefe (Apr 19 2021 at 14:27):
I think the association could possibly be many-to-many (for example: a state has separate storage locations for Moderna and Pfizer due to different storage requirements, each of which sends to the same administration location), but you could still correlate between them I think
Michael O'Keefe (Apr 19 2021 at 14:29):
That use case would imply that the upper bound on VTrckS PIN would want to be >1 though
Nell Lapres (Apr 19 2021 at 14:40):
Agree that it could be many to many. In our earlier discussions it sounded like the VTrcks pin was expected to be a unique identifier for a schedulable location. It sounds like we are not saying that here so want to make sure that is clear/allowed in the specs.
One other point, I do not expect all of our organizations have this stored in this system so it may be additional implementation work for organizations to implement (although it shouldn't be a prohibitive amount of additional work).
Ryan Owens (Apr 19 2021 at 14:46):
On our side, Nell's last statement generally represents my org's situation. We don't have the PIN in our scheduling system. We can get it in some of our cases but not all. We know the work required to add it. That work is not free though and will delay our ability to supply data by a not yet determined amount, but I would expect it to be measured in weeks, not days.
Josh Mandel (Apr 19 2021 at 15:09):
So as far as connectathon work goes, I think "include 1 or more VTrckS PINs if you have them, omit otherwise" is the right plan. We can bring this us as a discussion topic for our wrap-up meeting Thursday, and hopefully get some domain experts to join.
Rob Brackett (Apr 20 2021 at 07:06):
FWIW, I recall the question about VTrckS PINs coming up back when the proposed standard was an original thing and not FHIR-based. I think I had suggested VTrckS PINs would be good based on our experience in NJ, which at the time had a fairly 1:1 correspondence between actual locations we had identified and PINs (with a handful of locations not having a PIN, so we expected they’d just have a meaningless identifier). It seemed valuable to have a working identifier that multiple parties involved would presumably know about and which would help connect multiple systems. (There was no concept of other, additional identifiers in the design at that point.)
Since then, we’ve both learned about more locations in NJ where this wasn’t the case and have seen more ad-hoc clinics with no easily associatable VTrckS PIN, so if I were asked again, I’d agree with the conclusion here that VTrckS PINs may often be unavailable, and may not be the most useful as a location identifier anyway.
Josh Mandel (Apr 20 2021 at 15:30):
Thanks Rob!
Josh Mandel (Apr 20 2021 at 15:30):
We will aim to get the right folks from usds on our wrap-up call Thursday so we can talk through the details, but the assessment here seems compelling to me.
Josh Mandel (Apr 28 2021 at 01:58):
Thanks @Ryan Owens for the reminder on today's call; I fixed #33, on VTrckS PINs and advice on other identifiers -- https://github.com/smart-on-fhir/smart-scheduling-links/blob/master/specification.md#location-file has the updated guidance on Location.identifer.
Hemanth Gorur (Jun 08 2021 at 20:08):
{
"error_description": "The access token is missing",
"error": "invalid_request"
}
Rob Brackett (Jun 08 2021 at 20:10):
@Hemanth Gorur You might want to move that to the “Publisher: Kroger” topic: https://chat.fhir.org/#narrow/stream/281612-smart.2Fscheduling-links/topic/Publisher.3A.20Kroger
Patrick Stuart (Jun 16 2021 at 13:23):
I wasn't terribly clear after the call yesterday. Some people said it is required and others said it is not.
Should Rite Aid include this as a must-have or a nice-to-have or is it not necessary?
Thank you!
Rob Brackett (Jun 16 2021 at 16:29):
I think that depends on what you want the API to do for you. If you are just concerned with complying with the specification, including VTrckS PINs is a "should" in the truest sense: it is not a requirement, but is more than just a nice-to-have; it’s strongly encouraged if you have the data.
If you are concerned with implementing the specification so that your data shows up on vaccines.gov, that’s a very different matter, and @Hemanth Gorur is the person who can best tell you what’s required there.
If you are concerned with providing a useful public API for state & local governments or community health initiatives to do outreach work, get people vaccinated or do other analysis, VTrckS PINs are generally not a requirement, but super helpful. Having a real identifier that can be used to link stores up with other data (e.g. using a store number instead of the store’s zip code) is a virtual requirement.
Last updated: Apr 12 2022 at 19:14 UTC
