Code system reference for Immunization Value Sets

Yes, exactly.

Thanks Lloyd - sounds like something like this would be more compliant then, which differs from the CVC IG but is maybe the way it should be done?

If you're sending a SNOMED code, you *must* use the system "snomed.info/sct". Doing anything else is non-conformant with FHIR. Normally it would be up to the recipient to figure out which value set(s) the code happens to come from. However, if you need to convey what value set you were drawing the code from in the instance, there's a standard extension for that - build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-valueset-reference.html

Making up your own code system and sending a SNOMED code with that system isn't ok (and is possibly a violation of the SNOMED license).

Hi folks,

We faced similar challenges noted by Ken and Marc on an immunization project.

FHIR validators rejected a few of the systems as defined in the CVC IG because they are ValueSets, not CodeSystems, e.g.:

We tried switching to using the correct SNOMED CodeSystem and version (per Sheridan's message)

Unfortunately this introduced a different issue - consuming applications that were previously able to rely on the "system" values to identify the codes could no longer do so where multiple codings were present (e.g. to identify whether a vaccineCode was for a tradename vaccine or a generic).

We needed to support both FHIR Validation and existing client apps so had to compromise. We created our own NamingSystem references that passed validation but were also unique e.g.

Not an ideal solution, but necessary given our constraints.

There is history here around shifting away from national extensions and towards publishing as national editions - that more informed folks can weigh in on.

But from the perspective of what we should be doing as profile authors and implementers - we should be ensuring the national edition is leveraged and following the requirements outlined for expressing concepts in SNOMED CT National Editions in FHIR (i.e., system: of "snomed.info/sct" and a version: of "snomed.info/sct/20611000087101").

SNOMED modeling requirements aside, our experience with having properly modeled SCTCA FHIR valueSets (the others that Ken mentioned that we use in PS-CA) meant we could leverage them directly in tools that help us do things like validate against a terminology server (like THO) and leverage ConceptMaps for things like translation. Profiles like PS-CA and CA Baseline (and others in our community) point to the CVC catalog as it's the most up-to-date "one stop shop for all of the standardized content that these systems require to be interoperable".

But if those FHIR valueSets haven't updated to using the edition convention - it makes it harder for us a IGuide authors and testers to leverage really valuable capabilities in FHIR. And it makes it harder for us to stay aligned as a community when this creates divides in what gets modeled in our guides. A quick scan of the CA FHIR Registry shows that many of our older profiles have pointers to the CVC valueSet (without mention of code system) while some of the more recent profiles in BC and ON are profiling vaccine.code.system with fixedUri of "snomed.info/sct".

What does it take to solve this problem?

• Folks who have implemented concepts to include "fhir.infoway-inforoute.ca/CodeSystem/snomedctcaextension " as the code system or have profiled using the old convention - what impacts would you see if the valueSet output started using the system and version convention above? Could we mitigate these impacts through versioning?
• Folks who manage CVC - how hard would it be to update the modeling to reflect system and version for concepts in the next release so we keep getting value out of CVC valueSets as our sophistication in FHIR grows?

Thanks Ken.
The CVC administers/controls the CVCGeneric and CVCTradename value sets, so I guess they would have to make the update? Those value sets are based on the VaccineHistoricalNameCode and VaccineAdministeredTradnemameCode in Terminology Gateway, so the data for those subsets likely needs to be updated first.

In the context of a new implementation and an Immunization resource instance, what is the correct "system:" to use?