FHIR Chat · Consumer: USDS · smart/scheduling-links

Stream: smart/scheduling-links

Topic: Consumer: USDS

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

@Nick Robison I added a blank row for you in the sign-up spreadsheet -- can you add some details for the tools you're building, and goals for this event?

Josh Mandel (Apr 13 2021 at 18:31):

@Nick Robison as you are working on aggregation tools I wanted to bring up the technique from https://github.com/smart-on-fhir/smart-scheduling-links/issues/16#issuecomment-800283765 -- I think it would be good to include this kind of extension in any aggregated resources you are creating, so clients can tell how fresh or stale they might be. (This would effectively be a passthrough from the transaction time of the manifest files you consume, injected into each of the resources you create in your own server from those manifests.)

Nick Robison (Apr 13 2021 at 18:50):

Great point! I've defined a custom extension for retaining the original resource ID, I can add one to stash the update times as well.

Rob Brackett (Apr 13 2021 at 22:27):

@Nick Robison can you point to where you implemented that? Curious how you implemented the extension (e.g. what URL and value type) so I can do the same in APIs where I’m aggregating providers.

Rob Brackett (Apr 13 2021 at 22:27):

@Josh Mandel any sense of whether there’s a good way to push along https://jira.hl7.org/plugins/servlet/mobile#issue/FHIR-31567

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

You can do FHIR-31567 from mobile BTW and get a better link (FHIR-31567)

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

I'll ask FHIR-I to take this up on our next call (#fhir/infrastructure-wg)

Rob Brackett (Apr 13 2021 at 22:41):

Thanks!

Nick Robison (Apr 15 2021 at 13:04):

Good morning folks! Apologies for the delayed response to this.

@Rob Brackett The code for handling upstream IDs is here: https://github.com/nickrobison-usds/vaccine-scheduler/blob/d1cb938f665949c6a6c93c5bc7c08f9e09c60751/api-application/src/main/java/gov/usds/vaccineschedule/api/db/models/LocationEntity.java#L201

I've updated the code's handling of dates to match the discussion you and Josh have been having. Some details here: https://github.com/nickrobison-usds/vaccine-scheduler#resource-ids-and-timestamps

Basically, we're always using the lastUpdated value provided by the upstream (if one exists). We're also populating an additional extension http://usds.gov/vaccine/currentAsOf In the Meta component which indicates when the data was last refreshed on our end.

@Josh Mandel Happy to move the custom systems into a different namespace. E.g. does it make sense to have an original ID system in the SMART namespace, since it's applicable to pretty much all bulk FHIR implementations?

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

That's awesome! Regarding the extension namespaces, I'd like to take these into fhir infrastructure workgroup Monday and see if we can get them standardized as core extensions.

Henry Wei (Apr 16 2021 at 00:14):

USDS team: are you able to check / ask in-government if any of the FEMA Federally-Supported Community Vaccination Center providers may be showing up to the Connectathon (or their IT system providers)? More detail here: https://www.fema.gov/disasters/coronavirus/vaccine-support/vaccine-center

Thank you!

Rob Brackett (Apr 16 2021 at 15:03):

@Nick Robison thanks! (My turn for a slow reply.) I followed your lead on currentAsOf and used the same URL/system where we apply it on slots.

I’m doing upstream IDs a little different in our system, since we often wind up having many for a single location (e.g. vtrcks, NJ’s IIS, Walgreens Store #, external scraper like VaccineSpotter.org). For now I just set https://fhir.usdigitalresponse.org/identifiers/<SOURCE_NAME>, but wondering if there’s a better general rule we should use here.

On a related note, do you know if there are requirements around whether the system URL/URI needs to resolve (and to what)?

Josh Mandel (Apr 16 2021 at 15:09):

There is no requirement for extension URLs to resolve, though it's definitely a good practice!

Josh Mandel (Apr 16 2021 at 15:09):

(A good practice we're not adhering to in fhir-registry.smarthealthit.org ;-))

Josh Mandel (Apr 16 2021 at 15:10):

Incidentally even for a non-aggregation scenario I'm experimenting with extensions on the manifest file; not proposing anything at this stage, but just playing a bit. See https://raw.githubusercontent.com/jmandel/wba-appointment-fetch/gh-pages/$bulk-publish where some files might be older than others, based on underlying rate limiting

Josh Mandel (Apr 19 2021 at 19:24):

OK, FHIR Infrastructure approved a lastSourceSync extension on Meta (though for some super obscure reasons, we can't technically vote on anything until next month).

Josh Mandel (Apr 19 2021 at 19:27):

http://hl7.org/fhir/StructureDefinition/lastSourceSync

for use on Resource.meta.extension, with a valueDateTime. Example:

{
  "resourceType": "Slot",
  "id": "123",
  "meta": {
    "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/lastSourceSync",
      "valueDateTime": "2021-04-19T20:35:05.000Z"
    }]
  }
}

Rob Brackett (Apr 19 2021 at 19:58):

Whoops, I didn’t see this before I went and commented on the currentAsOf thread, sorry! This is great! :thumbs_up:

Rob Brackett (Apr 20 2021 at 21:08):

(deleted)

Rob Brackett (Apr 20 2021 at 21:17):

That was supposed to be in "Data Quality"

Last updated: Apr 12 2022 at 19:14 UTC