FHIR Chat · Must CodeSystem.uri and ValueSet.uri be disjoint? · terminology

Stream: terminology

Topic: Must CodeSystem.uri and ValueSet.uri be disjoint?

Michael Lawley (May 31 2018 at 04:10):

Is it a requirement that a ValueSet.uri must be different from every CodeSystem.uri?

Grahame Grieve (May 31 2018 at 07:52):

yes

Jim Steel (May 31 2018 at 23:52):

Is that documented anywhere?

Grahame Grieve (May 31 2018 at 23:56):

no. I don't think so. how can be the same?

Jim Steel (May 31 2018 at 23:57):

if you put the same string in one ValueSet's url field, and in one CodeSystem's url field?

Grahame Grieve (Jun 01 2018 at 00:32):

well, then, they won't be unique will tehy?

Jim Steel (Jun 01 2018 at 00:33):

No. But the question is, does that matter?

Grahame Grieve (Jun 01 2018 at 00:34):

yes

Grahame Grieve (Jun 01 2018 at 00:35):

The url... "SHOULD be globally unique"

Michael Lawley (Jun 01 2018 at 00:41):

SHOULD != MUST -- we're seeing some validation rules that enforce MUST

Grahame Grieve (Jun 01 2018 at 00:53):

well, we wanted to make that a SHALL but there's all sorts of weird edge cases that mean it can't be. but it would absolutely be WRONG for 2 resources to have the same canonical URL in scope

Rob Hausam (Jun 01 2018 at 00:57):

maybe I'm missing something - if it "would absolutely be WRONG" then why can't we make it SHALL?

Grahame Grieve (Jun 01 2018 at 01:02):

well, from memory... how do you construct a really unique identifier... what if domain names are reassigned? who do you know if someone else has created an resource that they shouldn't have? What would we say about versions an uniqueness?

Jim Steel (Jun 01 2018 at 01:03):

For one thing it would prevent having more than one version or edition of snomed in the system

Jim Steel (Jun 01 2018 at 01:03):

or any other code system

Grahame Grieve (Jun 01 2018 at 01:04):

no it wouldn't. but the detailed rules around that would have be elucidated completely if we made it a SHALL

Jim Steel (Jun 01 2018 at 01:05):

Its still not clear to me why it matters

Grahame Grieve (Jun 01 2018 at 01:06):

why what matters?

Jim Steel (Jun 01 2018 at 01:06):

Why having ValueSet and CodeSystem resources with the same uri is a problem

Grahame Grieve (Jun 01 2018 at 01:07):

well, because they can't resolve correctly. But more, it's expected that you can have a single dictionary of metadata resources by their url

Grahame Grieve (Jun 01 2018 at 01:08):

and some of my tools do tht

Jim Steel (Jun 01 2018 at 01:09):

They're URIs, not URLs. Its not necessary that the resolve, let alone resolve correctly

Michael Lawley (Jun 01 2018 at 01:22):

If we're talking about _resolve_ in the URL sense, then presumably you should end up at some kind of disambiguation page. But within a server you should always have context about the resource-type for the "URI" you are resolving - at least, we always do within Ontoserver.

Grahame Grieve (Jun 01 2018 at 01:28):

that assumes that the source location differentiates explicitly between the two kinds of resources. That's not true in the wider context of FHIR, where we sometimes refer to 'conformance resources' as a group - publishing contexts, for instance

Michael Lawley (Jun 01 2018 at 01:33):

but ultimately, the answer to my question is SHOULD, not SHALL, regardless of what technical difficulties this might impose

Grahame Grieve (Jun 01 2018 at 01:39):

I guess so.

Grahame Grieve (Jun 01 2018 at 01:40):

but it's very much a case of nearly nearly SHALL. I tried to thnk of various alternative phrasing... URLs SHALL not be used for more than one type of resource.

Grahame Grieve (Jun 01 2018 at 01:40):

but all come back to have the same problems.

Grahame Grieve (Jun 01 2018 at 01:41):

but we should make constraints:
CodeSystem.url != CodeSystem.valueSet
ValueSet.url != ValueSet.compose.include.system

Lloyd McKenzie (Jun 01 2018 at 01:43):

How about adding language that says "Tooling is likely to rely upon uniqueness of URLs."

Lloyd McKenzie (Jun 01 2018 at 01:44):

That at least explains to people that there are ramifications to not adhering to the SHOULD - and that they have no right to complain if they don't adhere to the guidance and their stuff doesn't work.

Grahame Grieve (Jun 01 2018 at 01:45):

well, it's slightly stronger than that - we can say that in some contexts, resources are referred to solely by their URL, and different resources that have the same URL are indistinguishable

Grahame Grieve (Jun 01 2018 at 01:46):

and the intent is that they are all different; the only reason that the rule is not SHALL is because of practical difficulties in edge cases

Michael Lawley (Jun 01 2018 at 01:47):

Well, the source of my question is that a Library we (want to) rely on (theorg.hl7.fhir.r4.validation.InstanceValidator) enforces this rule - SHALL semantics

Grahame Grieve (Jun 01 2018 at 01:48):

where? let me check, but that's certainly by design. There's no place where you can detect non-uniqueness that it's ok

Michael Lawley (Jun 01 2018 at 01:48):

It's in checkCoding()

Grahame Grieve (Jun 01 2018 at 01:49):

this: rule(errors, IssueType.CODEINVALID, element.line(), element.col(), path, !isValueSet(system), "The Coding references a value set, not a code system (\""+system+"\")");

Grahame Grieve (Jun 01 2018 at 01:49):

?

Jim Steel (Jun 01 2018 at 01:49):

Yep

Grahame Grieve (Jun 01 2018 at 01:49):

well, i stand by that rule, and we need to say whatever we can say in the standard to make that OK

Michael Lawley (Jun 01 2018 at 01:49):

code is

        rule(errors, IssueType.CODEINVALID, element.line(), element.col(), path, !isValueSet(system), "The Coding references a value set, not a code system (\""+system+"\")");

I want to have:

      if (!isCodeSystem(system)) {
        rule(errors, IssueType.CODEINVALID, element.line(), element.col(), path, !isValueSet(system), "The Coding references a value set, not a code system (\""+system+"\")");
      }

Jim Steel (Jun 01 2018 at 01:49):

It doesn't check for the non-existence of a CodeSystem with that URL

Grahame Grieve (Jun 01 2018 at 01:50):

I don't follow

Michael Lawley (Jun 01 2018 at 01:51):

or

      rule(errors, IssueType.CODEINVALID, element.line(), element.col(), path, isCodeSystem(system) || !isValueSet(system), "The Coding references a value set, rather than a code system (\""+system+"\")");

Grahame Grieve (Jun 01 2018 at 01:51):

I still don't follow.

Michael Lawley (Jun 01 2018 at 01:52):

If the system is a valid CodeSystem URI, then you don't care that it might also be a valid ValueSet URI

Grahame Grieve (Jun 01 2018 at 01:52):

I guess what you are saying is that you want to reuse ids and that it should be ok because the specification only says that you SHOULD not

Jim Steel (Jun 01 2018 at 01:52):

not Ids, URIs

Grahame Grieve (Jun 01 2018 at 01:52):

y uris. sorry

Grahame Grieve (Jun 01 2018 at 01:52):

I do care.

Jim Steel (Jun 01 2018 at 01:53):

The current code disables validation in this case, even though the presence of multiple resources needn't actually directly prevent it

Jim Steel (Jun 01 2018 at 01:53):

Seems overly dogmatic

Michael Lawley (Jun 01 2018 at 01:54):

and we don't want to, we just stumbled across this and it seemed "what @Jim Steel said" :-)

Grahame Grieve (Jun 01 2018 at 01:54):

I think it's good as it is. I agree it's a side issue, but one of the biggest problems we have is people confusing value sets and code systems and so I don't want to back it off

Grahame Grieve (Jun 01 2018 at 02:06):

is it a practical problem or a theoretical concern?

Michael Lawley (Jun 01 2018 at 02:15):

We're debugging now to determine that

Reuben Daniels (Jun 01 2018 at 02:22):

I agree with Grahame's comment about people confusing value sets and code systems. So I agree using the same value in both should be discouraged.

Lloyd McKenzie (Jun 01 2018 at 02:41):

It shouldn't just be discouraged - it's reasonable to treat it as an outright error.

Michael Lawley (Jun 01 2018 at 05:22):

I think I'm ready to say this is a concern of pedantry, not a blocker.
However, there's another real bug in code nearby:

              if (binding.hasValueSet() && binding.getValueSet() instanceof Reference) {
                ValueSet valueset = resolveBindingReference(profile, binding.getValueSet(), profile.getUrl());

resolveBindingReference can handle either a Reference or a UriType, but the code here never gives it a chance, so bindings to implicit (UriType) valuesets are ignored

Grahame Grieve (Jun 01 2018 at 05:34):

so...

Grahame Grieve (Jun 01 2018 at 05:34):

there's a reason for that.

Grahame Grieve (Jun 01 2018 at 05:35):

value sets bound to a url are outside the scope of the validator.

Michael Lawley (Jun 01 2018 at 05:53):

Why is it up to the IValidationSupport concrete implementation to determine that?

Grahame Grieve (Jun 01 2018 at 05:59):

umm?

Grahame Grieve (Jun 01 2018 at 05:59):

where is this code?

Michael Lawley (Jun 01 2018 at 06:05):

Sorry, that should have read why is it not

Grahame Grieve (Jun 01 2018 at 06:20):

because that definition comes from the spec, so why would it be up to an implementation?

Robert McClure (Jun 01 2018 at 15:56):

I'm really confused as why this discussion is focused on the technical requirements. The defining identifier for a value set can not be the same as a code system. And visa-versa. They are different things. I've not seen in this any example of something that MUST break that rule to work. So it's a SHALL.

Rob Hausam (Jun 01 2018 at 19:25):

So, (playing devil's advocate here) exactly what is going to happen if someone goes ahead and blatantly disregards the SHALL (assuming we would decide to make it that) and for some reason gives a code system and a value set the exact same url? When you use the url in an element binding in a resource or profile you will be referring to the value set. When you use the url in Coding.system you will be referring to the code system. And in ValueSet.compose, when it's used in include.system it will refer to the code system and in include.valueSet it will refer to the value set (and the same for exclude). In ConceptMap source and target it might not be clear which one you are referring to, but it also might not matter in most of the cases where anyone would ever do this. Maybe I've missed something, but I think this covers most of the uses. I agree that these are different things, and we should continue to tell people to make their identifying urls unique, but it doesn't seem that it's likely to be especially catastrophic if someone doesn't listen to that and goes ahead and in a few cases makes them the same anyway.

Grahame Grieve (Jun 01 2018 at 20:08):

it is because your situation only works in the terminology stack itself, where you know by context what type of thing you are referring to. In the publishing stack, we assume that the URLs are distinct and don't know what type of thing something is when resolving the URLs. Having two distinct artefacts with the same URL is fatal in publishing

Grahame Grieve (Jun 01 2018 at 20:09):

it would be good to add Rob's clearer statement - one not restricted by corner cases around global uniqueness - to the terminology pages.

Rob Hausam (Jun 01 2018 at 20:10):

Agree about the publishing stack generally.

Rob Hausam (Jun 01 2018 at 20:11):

Which is Rob's clearer statement?

Grahame Grieve (Jun 01 2018 at 20:15):

"The defining identifier for a value set can not be the same as a code system"

Michael Lawley (Jun 02 2018 at 07:57):

To answer @Rob Hausam 's question, it is the rule in the validation engine that would report a problem

Grahame Grieve (Jun 02 2018 at 08:01):

actually, the validation engine should report the problem first. that is, the loader I use should report the problem (HAPI loader might not)

Michael Lawley (Jun 02 2018 at 09:22):

ah, so the profile should fail to validate, not the instance

Rob Hausam (Jun 02 2018 at 12:12):

I think it makes sense to have the statement and the rule in validation (at least for the profile).

Michael Lawley (Sep 09 2019 at 06:06):

Okay, I'm going to re-open this discussion as it's just been brought to my attention that https://www.hl7.org/fhir/terminology-service.html#validation explicitly requires that a code system's URI can be used as a proxy for the "all codes defined in the code system" value set.

Every code system has an implicit value set that is "all the concepts defined in the code system" (CodeSystem.valueSet). For some code systems, these value set URIs are defined in advance (e.g. for LOINC, it is http://loinc.org/vs). However, for some code systems, they are not known. Clients can refer to these implicit value sets by providing the URI for the code system itself.

Now, I think the referenced use-case at the end is covered by CodeSystem/$validate-code so, in theory, this paragraph could be amended to suggest that operation is used instead

Last updated: Apr 12 2022 at 19:14 UTC