FHIR Chat · access violation from FHIR server · terminology / utg

Stream: terminology / utg

Topic: access violation from FHIR server

Ted Klein (Mar 30 2020 at 13:55):

Getting quite a few of these errors on the build:

Ted Klein (Mar 30 2020 at 13:56):

getting quite a few of there errors on the build:

Ted Klein (Mar 30 2020 at 13:56):

v3-CalendarCycle error Error from server: Unable to find value set "http://terminology.hl7.org/ValueSet/v3-CalendarCycleTwoLetter"

Ted Klein (Mar 30 2020 at 13:57):

But the value set is in the built IG at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v3-CalendarCycleTwoLetter.html

Ted Klein (Mar 30 2020 at 14:00):

it is unable to do an expansion based on: nclude these codes as defined in http://terminology.hl7.org/CodeSystem/v3-CalendarCycle. followed by the list of included codes. The code system is in the IG as well...this may be because we have not yet published the first UTG release so it cannot locate it, but it is able to locate the UTG code systems for other value sets. In any case, it probably should not throw an access violation I should think. @Grahame Grieve perhaps you can look at this if you get a chance? Trying to work though the errors on the QA report of the UTG build before we do the initial release.

Grahame Grieve (Apr 03 2020 at 12:52):

ok investigating this, the first problem is versions

Grahame Grieve (Apr 03 2020 at 12:52):

take, for example, the value set v3-OralInhalation

Grahame Grieve (Apr 03 2020 at 12:52):

Error from server: Unable to locate code ORINHL

Grahame Grieve (Apr 03 2020 at 12:52):

for this filter:

Grahame Grieve (Apr 03 2020 at 12:53):

<include>
      <system value="http://terminology.hl7.org/CodeSystem/v3-RouteOfAdministration"/>
      <filter>
        <property value="concept"/>
        <op value="is-a"/>
        <value value="ORINHL"/>
      </filter>
    </include>

Grahame Grieve (Apr 03 2020 at 12:53):

UTG is kind of special because it redefines a whole lot of code systems and value sets that are already in the base spec

Grahame Grieve (Apr 03 2020 at 12:54):

The validator/internal terminology services load the base spec first, and then they load the UTG resources.

Grahame Grieve (Apr 03 2020 at 12:54):

internally, the infrastructure is running full versioning, so loads them in parallel.

Grahame Grieve (Apr 03 2020 at 12:54):

the version of the code system in the base spec is 2018-08-1 while the version in UTG is 2.0.0. So an unversioned code system reference will be interpreted as referring to the base specification version

Grahame Grieve (Apr 03 2020 at 12:54):

I'm not sure how to think about this problem

Grahame Grieve (Apr 03 2020 at 12:56):

choices:

• remove all the terminology in UTG from the base spec as a technical correction (only, I don't know how to)
• make a special rule in the infrastructure for the UTG resources. Only, anyone else handling them will have to
• hack the versions so that the UTG version is more recent than the base version (3.0.0)? Only, we don't really want everything to be >3.0.0

Grahame Grieve (Apr 03 2020 at 12:57):

I guess there's an underlying problem I had been kicking into the future that has become due: the base package and the UTG package depend on each other, and package depedencies can't be recursive

Rob Hausam (Apr 03 2020 at 12:58):

Yes, some "interesting" issues to work through. Not sure what will be the best approach.

Ted Klein (Apr 03 2020 at 13:21):

Yes I have been concerned about this for months but was hoping it would not raise its head prior to our first UTG release. The most expedient solution, though ugly and may cause other issues down the road, is to choose a version # for all the UTG resources that evaluates to >2019-12-31. This would be a workaround, but I am not certain what further issues it might cause. Certainly an explanation for the ve3rsiong must be written for the UTG home page. Perhaps @Lloyd McKenzie or @Carol Macumber might have some suggestions?

Lloyd McKenzie (Apr 03 2020 at 16:15):

Going forward, none of the UTG terminologies should exist in the FHIR source at all (because if it's there, people will inevitably try to update it there). Which means that we're going to first load all of the structure definitions, extensions, etc. and they'll have references to value sets that don't exist in core. You'll then need to suck in the full UTG IG - which will give you all of those value sets. Only at that point can you check the references.

Lloyd McKenzie (Apr 03 2020 at 16:17):

Once we have stuff working for R5, we can think about how to make things work for R4. Certainly the desire is to be able to point to 'current' terminology, so R4 (and earlier) SHOULD be using UTG too, which would mean yanking the terminology out of the R4 release as a technical correction. Where we'll run into issues is with old releases that don't yet use the terminology.hl7.org code system URLs. For those, I think we'll have to stay "as is"

Rob Hausam (Apr 03 2020 at 18:33):

This sounds like a pretty sensible approach, generally.

Lloyd McKenzie (Apr 03 2020 at 19:20):

Sensible != easy :(

Ted Klein (Apr 04 2020 at 13:15):

yes, not so easy. Right now as long as the FHIR R4 source is pulled in on the Publish, the value sets in UTG can't find the correct code systems in UTG. Until the material gets yanked from R4 I don't know enough about how the publisher resolves this to see how to make it work in the next month or two. another potential approach, although I acknowledge it is aa dumb hack we will regret later, is to set the UTG versions to 2000.0.0, instead of 2.0.0 so the the publisher access these as the latest. This could be done quickly - in the next day or two - but I am unsure what other ramifications might ensue

Lloyd McKenzie (Apr 04 2020 at 14:27):

The biggest challenge will be how to process the UTG IG when core needs to use UTG. I suspect we'll have the same miserable situation where you need to use an old version of UTG in the publisher in order to build the new version of UTG - which is going to suck

Grahame Grieve (Apr 04 2020 at 20:06):

the biggest problem I have is the version. if core uses UTG, but UTG is using a particular version of core....

Ted Klein (Apr 04 2020 at 22:30):

Yes the recursively will kill it. How about the finesse it for now and set the version for all UTG stuff to 2020.0.0?

Carol Macumber (Apr 04 2020 at 22:36):

Ted Klein said:

Yes the recursively will kill it. How about the finesse it for now and set the version for all UTG stuff to 2020.0.0?

Ugh, I don't love that hack. Basically tricking it to pick up that version as the latest?

Ted Klein (Apr 04 2020 at 22:56):

yes that a was the thought. But it has to be selective - only for the objects (code systems and value sets) with a canonical URI under http://terminology.hl7.org. But I am not sure if this notion will actually work as I am unfamiliar with the internal workings of the Publisher.

Vassil Peytchev (Apr 04 2020 at 23:13):

Is there a way to carve out a stable API for the parts of Core that UTG uses, so that UTG can use the latest core, regardless of its own version?

Grahame Grieve (Apr 05 2020 at 10:48):

unfortunately not all the resources in UTG are normative:

• List
• NamingSystem
• ConceptMap

Though I'm not sure we have any concept maps right now

Ted Klein (Apr 05 2020 at 16:43):

No concept maps yet. We are making heavy use of NamingSystem where each instance is a "registry entry' of synonym code system identifiers in different HL7 standards family technologies, where we do not have the CodeSystem resource because the terminology is maintained and published outside of HL7. I will be putting in a tracker with the suggestion that a different type for NamingSystem can be "registryentry" but that is not germane to the fact that UTG uses it. We also use LIST for all of our manifests to control the rendering of code systems and value sets on the tabs, as well as a few other purposes. At this time UTG does not have any import of the FHIR code systems that have canonical URLs beginning with something other than http://terminology.hl7.org/ but I think (need to check) there may be some normative ones that have been brought in. We will use a LIST to identify those that cannot be modified through the UTG process, they must be done through the ballot process.

Grahame Grieve (Apr 05 2020 at 20:33):

there should be no normative ones

Ted Klein (Apr 06 2020 at 15:43):

OK I will check.

Grahame Grieve (Apr 07 2020 at 22:40):

@Ted Klein where the URL can't be the canonical URL: https://confluence.hl7.org/display/FHIR/Implementation+Guide+Parameters, see `special-url

Grahame Grieve (Apr 08 2020 at 01:50):

that text error:

Grahame Grieve (Apr 08 2020 at 01:50):

  </entry>"/>

on line 301. I've enhanced the error to report location correctly (well, as close as it possible)

Grahame Grieve (Apr 08 2020 at 03:58):

back to this... thinking about versions.

My first postulate:

• UTG cannot be used with versions earlier than FHIR R4

Grahame Grieve (Apr 08 2020 at 04:04):

my second postulate:

• R4+ can never be used without UTG

Lloyd McKenzie (Apr 08 2020 at 04:11):

I'm fine with the second. Does the first mean that an IG based on DSTU2 or STU3 won't be able to access the 'current' version of UTG-maintained terminologies?

Grahame Grieve (Apr 08 2020 at 04:15):

yes, if my postulate is applied

Lloyd McKenzie (Apr 08 2020 at 04:33):

I don't personally have any IGs that will care too much about that, but I expect some might. Do we need to post this proposition for wider feedback? Or is this something that is simply a fact of life like Covid where whether people like it or not doesn't much matter?

Grahame Grieve (Apr 08 2020 at 04:49):

I'm not sure. The problem is that change in code system URLs between 3 and 4 to clear the way for UTG

Lloyd McKenzie (Apr 08 2020 at 05:03):

Right - so you couldn't use the R3 URL if you're wanting to point to codes in UTG - but what if you make an STU3 profile and declare a dependency on UTG and use the new URLs ?

Grahame Grieve (Apr 08 2020 at 05:09):

now you have competing definitions of things between R3 and UTG, where as in R4, I can clean out everything in R4 that's in UTG

Lloyd McKenzie (Apr 08 2020 at 05:15):

Would they be seen as competing? They'd have different canonical URLs - It wouldn't be ideal, but I think it would work. The biggest issue would be different systems using different URLs for the same system - because one uses the old content and one uses the new.

Carol Macumber (Apr 08 2020 at 13:32):

@Lloyd McKenzie can we get around that differing URL issue with a namingSystem entry for the codesystem who's URLs have changed?

Lloyd McKenzie (Apr 08 2020 at 14:44):

We should have a NamingSystem that would help with that, but I don't know that most systems would be looking at that.

Last updated: Apr 12 2022 at 19:14 UTC