Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make canonical URIs resolvable #15

Open
masnick opened this issue Jun 1, 2023 · 5 comments
Open

Make canonical URIs resolvable #15

masnick opened this issue Jun 1, 2023 · 5 comments

Comments

@masnick
Copy link
Collaborator

masnick commented Jun 1, 2023

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
Copy link
Collaborator

how does this work with regards to versions?

@masnick
Copy link
Collaborator Author

masnick commented Jun 16, 2023

@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
Copy link
Collaborator

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
Copy link
Collaborator Author

masnick commented Jun 16, 2023

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants