When rebuilding an IG that was last built in February for a new release, new errors popped up with regard to the validation of a ConceptMap: ConceptMap​.group[0]​.element[1]​.target[0]​.code (l1​/c16202) error **The code '424877001' in the system http://snomed.info/sct is not valid in the value set ' https://www.ehealth.fgov.be/standards/fhir/mycarenet/ValueSet/be-vs-toothnumber-bodysite'** You can check this here: https://build.fhir.org/ig/hl7-be/mycarenet/branches/releasecandidate/qa.html It doesn't seem to be able to validate the codes in the appropriate valueset: As you can see here, all values are in the valueset: https://build.fhir.org/ig/hl7-be/mycarenet/branches/releasecandidate/ValueSet-be-vs-toothnumber-bodysite.html What is happening? You can reproduce this using this IG: https://github.com/hl7-be/mycarenet , branch: releasecandidate.

definitely a bug somewhere between the validator and the server

fixed-ish in the next release

Hi @Grahame Grieve , today we were checking this issue again, and it appears not to be fixed. Am I missing something? See: https://build.fhir.org/ig/hl7-be/mycarenet/branches/releasecandidate/qa.html#_scratch_repo_fsh-generated_resources_ConceptMap-BeCMISOToothSnomedCT Is there something I can fix in the definition of the map?

did you try clearing the tx-cache?

I am not supposed to clear the cache on the build server, am I? A new build always starts from a clean sheet...

you local one? are you sure?

@Grahame Grieve The build I am referring to (: https://build.fhir.org/ig/hl7-be/mycarenet/branches/releasecandidate/qa.html#_scratch_repo_fsh-generated_resources_ConceptMap-BeCMISOToothSnomedCT ) is done on build.fhir.org ... That build cannot be influenced by what I do locally, can it?

@Grahame Grieve I created https://github.com/hapifhir/org.hl7.fhir.core/issues/2062

I commented on the issue - this might related to something I ran into: #committers > ValueSet validation issue?

well, whatever code I wrote to solve this problem has evaporated

so it's not going to get addressed until the second week of July, sorry

at least I'll solve it properly then

This thread has gone quiet but it seems like what's happening to me. https://build.fhir.org/ig/HL7/ccda-on-fhir/branches/de-profile/qa.html The source code 'BAD' is not valid in the value set http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.1.11.10637|20170915 I don't know where the version # came from but CTS doesn't like it. Might there be a publisher setting to turn it off?

this is on my list - something has definitely gone wrong on my side, and I'm not sure what. But I'm days away at the moment

Claude thinks it's in FHIR Core, not Publisher, tho Publisher could add special handling. Seems to me like a mismatch in CTS output and input.

here's the problem: image.png

your vsac dependency is on 0.3.0 - prehistoric

as in... @Jay Lyle you don't need to have vsac as a dependency anymore.

well, not so simple, because it depends on packages that depend on vsac

Thanks for your persistence. Ok, assume an outdated dependency could cause an effect like that. The IG source doesn't assert that dependency. There was one incorrect url with 'vsac' in it, but I fixed that and cleared the cache and the build looks the same. So, is the question not "how's that VS version getting in that concept map?" but "how's that package version getting in wherever it's getting?"

It’s 8n my image above

You’re depending on an old version of C-CDA which depends on an old version of US core which depends on that old version of VSAC

So if ccda-on-fhir would depend on a newer version (what version has this vsac dependency fixed?) of us-core, the problem goes away?

well, it'll change, at least

US Core 5 doesn't help but 6 does. All errors quashed, for now. And the vsac warnings are gone, but now we have similar ones: The code 'P' comes from the system http://terminology.hl7.org/CodeSystem/v3-EntityNameUse version 2023-02-01 which could not be found, so it's not known whether it's valid in the value set 'null' As before, something is appending a version to the stated URL and then complaining that it won't resolve. The source value set it's calling 'null' is http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.1.11.15913 , one of the ones we updated from the vsac url.

There are also some complaints about unresolvable page links (which resolve for me). These are tagged 'error' but they don't show up in the header count.

https://build.fhir.org/ig/HL7/ccda-on-fhir/branches/de-profile/qa.html

The unresolveable page links ... are you speaking of image.png You can't use hyperlinks to another IG unless that other IG is a dependency. You are now depending on us-core 6.1.0. You should look at using {{site.data.foobar}} so that your links follow what you are depending on.

The current infrastucture does get really picky of canonicals that don't have a version. So you are getting many warnings about this. You can either fix up each of your canonicals with the version you want, or you can use the publisher parameters to pin canonicals

for fun I tracked this warning image.png http://tx.fhir.org/r4/CodeSystem?system=urn:oid:1.3.6.1.4.1.22812.3.2009316.3 which returns MANY codeSystems (2007 of them). So, is this the right system value?

That site seems to return 2007 systems no matter what you ask it. But thanks for the pointers.

I agree there seems to be something that @Grahame Grieve is needed

which returns MANY codeSystems (2007 of them). So, is this the right system value? because the query should be http://tx.fhir.org/r4/CodeSystem?url=urn:oid:1.3.6.1.4.1.22812.3.2009316.3

which is empty

because of urn:oid:1.3.6.1.4.1.22812.3.2009316.3, is not known

im am embarrassed. should have not made that mistake.

nah, the UI makes that too easy. I've tightened that up for next upgrade

Modified all refs from US Core 4 to 6. Minor tweaks to align, fortunately. Added versions to all THO system refs. Most problems gone. One VS continues to complain "The target code 'L' is not valid in the value set http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.1.11.15913|20210630 " Once again, something is adding a version tag and then complaining that it doesn't recognize it. We assert http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.1.11.15913 , in which 'L' is valid. While we versioned all systems, we did not version value sets; only this one complained. "20210630" doesn't seem to be an expansion in VSAC. Adding "|20210630" doesn't fix it. Additional detail: It's writing the link " https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.1.11.15913/expansion " where we'd specified " http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.1.11.15913 "

the link being different is correct - that's the browser link not the definition URL

The code system ' http://terminology.hl7.org/CodeSystem/v3-EntityNameUse ' version '2023-02-01' in the ValueSet include is different to the one in the value ('4.0.0')

@Bryn Rhodes I think that this is another vsac issue? That's not a version we've ever defined

so is this all sorted with the latest release?

Remaining: HTML fragments, seemingly from the build process (2) SCT US edition is fixed in expansion parameters; IGP doesn't seem to see that. Maybe a Sushi thing.* Instructions to consider more recent releases (US Core, extensions) (2). Prefer not to. IGP can't find 2 CCDA-asserted OID-based value sets (NKA) (4) IGP can't find identifier systems (10). It shouldn't.

*migrating to fsh after this publication

HTML fragments, seemingly from the build process I don't know what that means SCT US edition is fixed in expansion parameters; IGP doesn't seem to see that. it should. why do you think it doesn't?

https://build.fhir.org/ig/HL7/ccda-on-fhir/branches/de-profile/qa.html An HTML fragment from the set [cross-version-analysis.xhtml, cross-version-analysis-inline.xhtml] is not included anywhere in the produced implementation guide The HTML fragment 'globals-table.xhtml' is not included anywhere in the produced implementation guide In US Core, the expansion parameter seems to be consumed by Sushi. We're not using fsh yet, so it wouldn't be. It doesn't show up in the output, either way.

An HTML fragment from the set [cross-version-analysis.xhtml, cross-version-analysis-inline.xhtml] is not included anywhere in the produced implementation guide The HTML fragment 'globals-table.xhtml' is not included anywhere in the produced implementation guide so include those fragments somewhere. If you don't understand why you should do that, then you search through the back history here on Zulip In US Core, the expansion parameter seems to be consumed by Sushi. We're not using fsh yet, so it wouldn't be. It doesn't show up in the output, either way. it affects which version of snomed gets used, and that shows up in the output.

SNOMED The only place we mention a US Edition code is in an example. The IGP seems to check those, since it complains about examples with identifier systems it doesn't know, but it doesn't complain about the example US Edition code. So it seems able to employ the US edition as declared in parameters to check the example, but it doesn't know that it was declared. HTML OK. Back in a few days.

So it seems able to employ the US edition as declared in parameters to check the example, but it doesn't know that it was declared. so it does know. But apparently you're expecting something other than just knowing

It must know when it tries to use it. If it does use it. But it complains that it's not declared. Which isn't true, but we haven't figured out how it wants it. I'm expecting to be able to silence the warning.

found the syntax for embedding the html it wants to see.

what complains that's what not declared?

" warning The IG is not for the international realm, and it uses SNOMED CT, so it should fix the SCT edition in the expansion parameters "

oh interesting. how do I reproduce that?

No idea. It's here: https://build.fhir.org/ig/HL7/ccda-on-fhir/branches/de-profile/qa.html I've tried using expansion-parameters and exp-params (following us core). Might IGP be assuming Sushi is in the mix?

no, IGP never assumes. you have to tell IGP where your expansion parameters file is in the IG resource. <parameter> <code value="path-expansion-params"/> <value value="<path to your expansion parameters file"/> </parameter> That needs to be in your IG resource otherwise the IGP has no idea that you have an expansion file.