Stream: IG creation
Topic: UTG
Grahame Grieve (Jul 21 2020 at 10:45):
Next release of the Publisher, UTG will automatically become in scope; any terminology references to content in UTG will automatically start using the latest version of UTG unless you specifically add UTG as a dependency, and specify an alternative version
Grahame Grieve (Jul 21 2020 at 10:46):
The only reason I can think that this would be a reasonable thing to do is if you need to depend on the current build rather than the most recent release
Ted Klein (Jul 22 2020 at 22:11):
@Grahame Grieve @Jose Costa Teixeira The releases of the Publisher post version 0.0.100 have gotten incrementally worse for the generation of UTG, and I figured it is time I brought this to your attention in case you are not aware. The change Grahame made scores of releases ago so that value sets with CLDs with enumerated content giving a warning but not a hard error when the underlying code system is not available but still generating the value set in the output appears to have been undone. There are other gremlins...I am still using 0.0.100 locally as it gives a much cleaner build and I can hunt down the real errors. How do we want to go about addressing this?
Grahame Grieve (Jul 22 2020 at 23:09):
it wasn't knowingly undone. Where's an example?
Ted Klein (Jul 23 2020 at 01:21):
In my local build using IGP 0.0.100, the value set "v3-AudiologistHIPAA" gives no error. In the ci build version 1.1.2, we get the error: /scratch/ig-build-temp-EAUEMD/repo/input/sourceOfTruth/v3/valueSets/v3-AudiologistHIPAA.xml
Path Severity Message
ValueSet/v3-AudiologistHIPAA: ValueSet (l3/c39) Process Info Validate resource against profile http://hl7.org/fhir/StructureDefinition/ValueSet
ValueSet.where(id = 'v3-AudiologistHIPAA') error Error from server: Unable to locate code 231H00000N (see Tx log). There are now MANY like this.
Ted Klein (Jul 23 2020 at 01:23):
and consequential errors from all the ones that include the other ones in their <compose>, so these cascade. True for the HIPAA ones, the MSH codes, other enumerated stuff - dozens.
Ted Klein (Jul 23 2020 at 01:25):
a raft of build errors as well where is cannot find a bunch of files (xml, json, ttl, html etc) for several that are not building - works just fine in 0.0.100; so dunno exactly what is going on.
Grahame Grieve (Jul 23 2020 at 03:52):
ah so this is the result of additional validation checking in the IG Publisher
Grahame Grieve (Jul 23 2020 at 03:53):
I wasn't checking that valueset.compose.include.concept.code is actually valid, and now I am checking
Rick Geimer (Jul 23 2020 at 13:04):
Guessing that might explain this error:
Stack Dump (for debugging): (00:26.0101)
java.lang.NullPointerException
at org.hl7.fhir.igtools.publisher.Publisher.dependsOnUTG(Publisher.java:1867)
at org.hl7.fhir.igtools.publisher.Publisher.initializeFromIg(Publisher.java:1751)
at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1363)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:700)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:7811)
BTW, it seems to be intermittent, so maybe a UTG connectivity issue?
Ted Klein (Jul 23 2020 at 15:30):
so if the ValueSet.compose.include.concept is from a code system that is not in the IG and not in the server, IMHO that should be a warning not a hard error, and you should generated the value set in the IG output anyway. Same if the include is for a system that is external or outside the IG. To do a better job, it would be best if we had an IG parameter that declared a system as being outside the IG and maybe unknown to the server and thus should NOT trigger an error on validate as it is explicitly to be included by the IG author.
Ted Klein (Jul 23 2020 at 15:31):
perhaps the IG parameter 'special-url' which we already have and use can serve this purpose?
Grahame Grieve (Jul 23 2020 at 18:51):
@Rick Geimer you should not be getting that error because that code is not released at this point in time. You should take up with @Sean McIlvenna why trifolia is using the dev branch of the publisher. I do not - and will not - support it's use in production.
Having said that, I can't see how you get that error. but I can't track it down because it's not the right line
Sean McIlvenna (Jul 23 2020 at 19:15):
We talked about this when you were getting ready to start using GitHub releases... I explained that ToF uses SonaType to get the list of IG Publisher versions (and to ultimately download the selected IG Publisher version). I asked whether or not that would break after you started using GitHub releases, and was told that it would not, and we would have time to adopt the new approach. So, I have backlogged updating ToF to use GitHub releases until a time that it is a priority.
Grahame Grieve (Jul 23 2020 at 19:20):
what you didn't say was that this would mean you would stop using the current release and start using the current dev snapshot
Grahame Grieve (Jul 23 2020 at 19:20):
because that would've changed my answer
Grahame Grieve (Jul 23 2020 at 19:26):
no I see that this should have been obvious but it wasn't apparent to me
Sean McIlvenna (Jul 23 2020 at 20:50):
I'll try to take some time tomorrow to update ToF to use GitHub releases instead of SonaType
Sean McIlvenna (Jul 23 2020 at 20:51):
really depends on how my day goes
Rick Geimer (Jul 24 2020 at 15:41):
And Trifolia supports multiple versions of the publisher, so for the moment we are just instructing people to select 1.1.3 vs. the default (which is incorrectly selecting 1.1.4 as you have pointed out). So easy workaround until Sean makes his fix.
Last updated: Apr 12 2022 at 19:14 UTC
