Stream: IG creation
Topic: invalid IG parameters being added to IG
Jean Duteau (Nov 01 2021 at 18:15):
Using IG v1.1.84 with FHIR version 4.0.1, I get an IG resource that has definition.parameters with codes of 'path-resource', 'path-pages', and 'path-tx-cache'.
with FHIR version 4.1.0, I get an IG resource that has invalid definition.parameter.codes: path-liquid, path-qa, path-temp, path-output, apply-jurisdiction, etc.
In both cases, my input IG is the same and doesn't have those codes. There appears to be some fhir version-specific code that causes these parameters to be output even though they are invalid.
Grahame Grieve (Nov 01 2021 at 20:44):
I get an IG resource
where?
Lloyd McKenzie (Nov 01 2021 at 21:32):
The parameters get inserted by the template process. However, I thought we had a mechanism so the process didn't choke on them...
Jean Duteau (Nov 02 2021 at 01:29):
@Grahame Grieve the fhir-spl guide. I’m just switching it over to use R4B and encountered those errors. It’s in the IG that gets produced in output.
@Lloyd McKenzie the validator is complaining about all the codes. I would assume that the templates are the same whether I use 4.0.1 or 4.1.0 so it seems something else isn’t stripping them?
Grahame Grieve (Nov 02 2021 at 01:30):
it's in the input or the output?
Lloyd McKenzie (Nov 02 2021 at 02:08):
The template puts the content in the input.
Jean Duteau (Nov 02 2021 at 02:19):
In the output. When I look out the output/ig.json, all of the improper codes are there. I didn’t look in the temp but my input Ig doesn’t have them
Grahame Grieve (Nov 02 2021 at 02:20):
well, then it's not going to be valid. That's according to the specification itself. It's not clear to me what I should do about it
Jean Duteau (Nov 02 2021 at 02:32):
What I don’t understand is why I’m getting a different IG depending on which fhirVersion I specify. Why would that matter?
Jean Duteau (Nov 02 2021 at 02:32):
@Lloyd McKenzie is there code in the templates that depends on fhirVersion that might be causing this?
Lloyd McKenzie (Nov 02 2021 at 02:36):
I don't believe so. To be honest, I'm not sure why it wasn't complaining before.
Lloyd McKenzie (Nov 02 2021 at 03:03):
Out of curiosity, do you get the same issue if you try building locally with a publisher from say a month or so ago?
Jean Duteau (Nov 02 2021 at 03:12):
I’ll try that later. Just to recap though, specifying 4.0.1 doesn’t give the invalid codes in the Ig while 4.1.0 does.
Lloyd McKenzie (Nov 02 2021 at 03:14):
Ah. Maybe we do something special for 4.0 and earlier, but the builder assumes that > 4.0.x is an R5 IG and thus all is good. And you're the first author of an R4B IG.
Lloyd McKenzie (Nov 02 2021 at 03:14):
Troublemaker... ;)
Jean Duteau (Nov 02 2021 at 03:18):
I take pride in being a troublemaker and pushing the envelope but I think that I got those errors when I put 4.6.0 first.
Lloyd McKenzie (Nov 02 2021 at 05:02):
That'd be super weird, because R5 doesn't constrain the set of parameters - it's an unbound string
Jean Duteau (Nov 02 2021 at 05:11):
yes, you're right. So temp IG has those parameters for both 4.0.1 and 4.1.0, but 4.0.1 somewhere turns the invalid coded parameters into extensions while 4.1.0 doesn't
Jean Duteau (Nov 03 2021 at 03:58):
@Lloyd McKenzie do you have a potential fix to this that I could try?
Lloyd McKenzie (Nov 03 2021 at 05:15):
@Grahame Grieve The issue is that VersionUtilities.isR4Ver() determines whether something is an R4 version based on whether the version starts with 4.0 - which means that 4.1.x releases aren't included, which means that R4B stuff is not converted down to R4 from the R5 version that we use internally. Given that (I believe) we don't convert any of the resources that change in R4B, I think it should be safe to change this logic to return true if the version starts with 4.0 or 4.1. Thoughts?
Grahame Grieve (Nov 03 2021 at 05:16):
no, don't do that. Because it does matter very much in some places. Instead, add a isR4orR4BVer, and call that where this decision is made
Lloyd McKenzie (Nov 03 2021 at 05:45):
The decision is made when spitting out resources - there's no special processing for the ImplementationGuide
Jean Duteau (Nov 22 2021 at 17:45):
okay, @Giorgio Cangioli and I have IGs that based on R4B and there might be others. I'm now actively working on this IG and the vast set of errors that are being generated are making it hard to see the real errors that I'm injecting into the IG. Is there something we can do to fix this issue that R4B is considered R5 when spitting out resources? (@Lloyd McKenzie @Grahame Grieve)
Grahame Grieve (Nov 29 2021 at 09:41):
they'll go away next release
Jean Duteau (Nov 29 2021 at 14:12):
Thx grahame
Last updated: Apr 12 2022 at 19:14 UTC
