dvci / shc-terminology

Terminology assets for supporting SMART Health Cards
Creative Commons Zero v1.0 Universal
4 stars 1 forks source link

Make canonical URIs resolvable #15

Open masnick opened 1 year ago

masnick commented 1 year ago

A canonical URI like https://terminology.smarthealth.cards/ValueSet/immunization-covid-cvx should resolve to the content from https://terminology.smarthealth.cards/ValueSet-immunization-covid-cvx.html.

We can either do JavaScript redirects or have an Action copy the existing .html file to desired location. Note that GitHub Pages allows for .html to be left off of a URL and still resolve.

grahamegrieve commented 1 year ago

how does this work with regards to versions?

masnick commented 1 year ago

@grahamegrieve the naive way this would work is to always display the most current version at the canonical URL.

I believe these ValueSets should never remove any codes (excepting things like typos) to allow for proper identification of historical SHCs (e.g., a COVID SHC using a deprecated code). Accordingly, I expect our users would not have a reason to use any version except the most current one.

If this approach is too naive, we may need a separate discussion about versioning and a release cadence...right now this IG is really set up to support "get the most recent version" and "tell if your cached version is out of date", but nothing else.

nathanbunker commented 1 year ago

From my experience, we do not remove vaccine codes. For CVX and NDC they are only created when they are going to be administered, and once they are administered under that code we can't ever get rid of the code, just as Max says, to support older administered records. So I don't think the approach is naive. I agree that folks will only ever want the most recent version.

We are looking at projects to add annotations/meta-data to vaccine codes to specify when they might have been used for reporting administered immunizations. But the code itself will remain valid for use in current transactions, even if only to support messaging historical immunization records.

masnick commented 1 year ago

We could also presumably annotate inactive codes in the ValueSet.

Looking at the FHIR spec, the only way I could find to do this is setting ValueSet.compose.include.concept.designation.use to something like snomed#900000000000546006 ("Inactive value (foundation metadata concept") and ValueSet.compose.include.concept.designation.value to a short narrative explanation. I'll ask on Zulip if there is a better way to do this.

Edit: https://chat.fhir.org/#narrow/stream/179202-terminology/topic/ValueSet.20with.20inactive.20concepts

nathanbunker commented 1 year ago

The CDC does label codes as "inactive" as they want to discourage their use for newly administered vaccinations. We have a terrible time trying to stop people from removing these "inactive" codes completely from their systems. They interpret "inactive" to mean that they shouldn't accept or send them. We spend a lot of time explaining that all, or nearly all, the currently inactive codes should be considered active for most purposes. For communicating immunization history I would lean towards not telling people what codes are "inactive". For a SMART Health Card maybe it would make sense not to bother, especially if it's only recording what has happened and wouldn't effect administrators experience with giving vaccinations.