FHIR Chat · Local CodeSystem declaration · terminology

Stream: terminology

Topic: Local CodeSystem declaration


view this post on Zulip Alexander Henket (Aug 25 2020 at 14:02):

After examining complaints from the IG Publisher about unknown code systems I decided to have a look at our CodeSystem situation. We have 93 distinct local code systems to deal with. Some identified with a URI and most based on urn:oid:.

Because this is STU3 there is also the odd system that got a URI assigned in R4. This concerns 1.3.160 or GTIN.

I would like to help implementers by supplying more formal information on these codesystems than we currently do, and hopefully satisfy the IG Publisher in the process.

I can think of two ways, or both:

  • Add CodeSystem resources for each, outlining copyrights, where to get them (we seldom own them) etc. and use CodeSystem.content = not-present
    • Big note: the CodeSystem.url will be urn:oid:... for these systems where applicable
  • Add NamingSystem that does that same thing except that it does not have the burden of content and concentrates on meta only.

Any advice to share which is preferred?

view this post on Zulip Jean Duteau (Aug 25 2020 at 14:35):

I've done #1 for my Da Vinci guide where I have X12 code systems. I call them "stub" code systems as they aren't code systems that you can use (since the content isn't present) but it gives the URL (or OID in your case), some definitions, and potentially some copyright information.

view this post on Zulip Rob Hausam (Aug 25 2020 at 16:33):

The decision at least partly comes down to who is in control of the code system and how much and what types of metadata are available for it. The CodeSystem resource should represent the point of view and the content determined by the code system owner/publisher (although someone else, such as yourself, might actually create the resource instance). If the metadata includes the copyright and many of the additional items (including properties, filters, etc.), then CodeSystem is the only way that we have to represent that. If you have multiple identifiers of one or more identifier types (e.g. an oid and a url, or multiples of those) and need or want to declare or obtain the preferred identifier for a type, then obviously NamingSystem is needed for that. So in some cases you may need both.

view this post on Zulip Grahame Grieve (Aug 25 2020 at 21:31):

I didn't write the terminology sub-system used in the validator and the publisher to deal with the situation where a package declares a code system stub for a code system that tx.fhir.org handles. By default, the stub hides the tx.fhir.org server's support for the code system. But stubs like this are appearing in multiple places, especially UTG, and so I am hunting down all these places and trying to figure out whether the stub should be referenced or not.

This is to say: if you declare those as code system stubs, you may get unexpected side effects. We can discuss/debug

view this post on Zulip Alexander Henket (Aug 26 2020 at 11:42):

My intention after reading all this, is to create both CodeSystems and NamingSystems for each of the 93 systems. From there I intend take the discussion to the IG creation stream if unexpected things turn up there.

view this post on Zulip Rob Hausam (Aug 26 2020 at 12:48):

Of course it would be good to also bring relevant issues/questions back to this stream, as well (in addition to IG Creation).

view this post on Zulip Alexander Henket (Sep 01 2020 at 09:38):

Sure. If I run into issues creating the shell CodeSystems I'll check in here. Maybe one thing:

  • FHIR juggled URIs from STU3 to R4 for all HL7 systems
  • Every once in a while a new URI gets added e.g. for GTIN in R4, where we use the OID in STU3

This means that for us in STU3 we stick with what was known in STU3, and expect to move to R4 system identification when we move to R4. We cannot convert while in production with STU3.

The value proposition of ever changing identifiers is not very good. We had stable OIDs for 15-20 years, and now FHIR changes identifiers from OIDs to URIs and then from URIs to different URIs. All without helping patients. I've expressed this before.

My main question is really about what the experience with this is so far. Do people check NamingSystems? Does an STU3 NamingSystem have a different preferred identifier for the same system than R4? That would be my expectation. Would it be correct to even list the R4 GTIN URI in an STU3 NamingSystem? How does all this interrelate with CodeSystem.url? STU3 GTIN CodeSystem and R4 GTIN CodeSystem would be virtually different systems based on their canonical.

view this post on Zulip Grahame Grieve (Sep 01 2020 at 09:43):

In general, we should not be changing code system URIs once they are defined. The change to terminology.hl7.org was very much a once off.

view this post on Zulip Alexander Henket (Sep 02 2020 at 13:49):

I was counting on that. But given the life span of STU3 implementations it does raise long term questions.

view this post on Zulip Grahame Grieve (Sep 02 2020 at 20:27):

yes i hear you. It's painful but it's also definitely in the trial-use space, and the committee decided to make the change based on the outcome of the trial use

view this post on Zulip Peter Jordan (Sep 02 2020 at 21:25):

Alexander Henket said:

My main question is really about what the experience with this is so far. Do people check NamingSystems? Does an STU3 NamingSystem have a different preferred identifier for the same system than R4? That would be my expectation. Would it be correct to even list the R4 GTIN URI in an STU3 NamingSystem? How does all this interrelate with CodeSystem.url? STU3 GTIN CodeSystem and R4 GTIN CodeSystem would be virtually different systems based on their canonical.

It's certainly possible to use the NamingSystem resource for identifier translation. There isn't currently an operation to do this, although one has been proposed for R5 JIRA 26837. I've created a custom operation to do this on my R4 Server as, in addition to OID to URI changes as we move from CDA to FHIR, an NZ government dept has already changed a group of identifiers used in production FHIR R4 systems.

view this post on Zulip Michael Lawley (Sep 03 2020 at 05:08):

It is also arguable (intended) that when a terminology server resolves a CodeSystem URI it should look at its NamingSystems as part of the process.
Ontoserver doesn't do this (yet). I don't know what other systems do - @Grahame Grieve @Peter Jordan @Rob Hausam ?

view this post on Zulip Grahame Grieve (Sep 03 2020 at 07:55):

I'm not sure that my server does yet. The mini-terminology server in the validator does

view this post on Zulip Peter Jordan (Sep 03 2020 at 10:41):

Terminz uses Naming System resources for converting the Code System OIDs in CDA documents to FHIR CodeSystem URIs, but I need to extend this for resolving URIs where CodeSystem URIs have (already!) been changed by their owner.


Last updated: Apr 12 2022 at 19:14 UTC