I'm getting new messages for HRex: INFORMATION: ValueSet/hrex-consent-policy: ValueSet.compose.include[0]: The concepts in the value set include have not been validated because the code system is not known, and no terminology service supports it WARNING: ValueSet.where(id = 'hrex-consent-policy'): Error from https://tx.fhir.org/r4: Error: A definition for CodeSystem 'urn:ietf:rfc:3986' could not be found, so the value set cannot be expanded It's fine to not validate the codes against the code system, but the value set is intensional, so it's definitely possible to check that the codes are in the value set, even if you don't know if they're valid against the code system. Why has this functionality changed?

because I thought maybe I can annoy you

Turnabout is fair play...

It's fine to not validate the codes against the code system, but the value set is intensional, so it's definitely possible to check that the codes are in the value set, even if you don't know if they're valid against the code system. Why has this functionality changed? I don't understand what you're saying. What's the point of checking that the codes are in the value set, when you're validating the value set? It means what it says, and nothing changed here

An extensional valueset can be expanded. The list of codes is already in the value set. The fact the tx server doesn't have access to the code system is immaterial. It'd be ok to provide a warning indicating that retired codes won't have been removed, but at least then the validation process would work, as would slicing.

you're still not paying attention to what's going on here

"A definition for CodeSystem 'urn:ietf:rfc:3986' could not be found, so the value set cannot be expanded" is saying it can't expand. And that's not true. Extensional value sets can be expanded whether the code system can be found or not.

What am I missing?

I do not expand them. I don't even know whether the code system is valid. But you're confused when you say "at least then the validation process would work, as would slicing." this has nothing to do with slicing

@Lloyd McKenzie are you saying the following can be validated when " http://loinc.org " is not available? Self-consistency != validity { "resourceType" : "ValueSet" , "compose" : { "include" : [{ "system" : "http://loinc.org" , "concept" : [{ "code" : "A" }] }] }, "expansion" : { "contains" : [{ "system" : "http://loinc.org" , "code" : "A" , "display" : "tricked you" }] }

Lloyd's view is always that you have to prove it's wrong, or it's not wrong

that's not how a terminology service should behave, and one reason for the detail codes

If I have slicing that's based on membership in a value set, if the value set can be expanded, I can check if the code is in that valueset. If you just say "I can't check if the code exists in the code system, so you're out of luck", that's not useful. It's completely reasonable to warn and say "The expansion hasn't been validated against the code system". And yes, if the value set is badly constructed, it could contain codes that aren't actually valid. That's the fault of the value set. The terminology server is just telling you what the value set says and saying it doesn't have further information. The reality is that it's not going to be uncommon for value sets to exist in a terminology server where the code system doesn't exist. In the case of the X12 codes, they won't ever exist in a public terminology server, and it's not a given they'll exist in terminology servers at all (payers won't necessarily bother with terminology servers to check the codes). A terminology server should never say "this is invalid" if it doesn't know. It should say "I don't know". Otherwise, it's lying.

this is getting tedious. the error relates to validating the contents of the value set itself

The TS server message is "Error: A definition for CodeSystem 'urn:ietf:rfc:3986' could not be found, so the value set cannot be expanded". If that's talking about validating the value set itself, the message is misleading. What is it trying to actually convey?

it's telling the author of the value set that it can't be expanded

how is that misleading as a warning on the value set?

But it can be expanded. The information to expand it is there. I would expect $expand on that valueset to work just fine (with the possible exception of a warning about the inability to check the codes). Are you saying codes can be validated against it even if it doesn't expand?

my terminology server will neither expand nor validate. In the absence of a code system definition, I do not trust value sets.

That's a problem - because you'll never have a code system definition for lots of code systems. The one in question here is the code system urn:ietf:rfc:3986, and there's no chance of you ever having a definition for it. But it's still necessary for us to be able to validate against such value sets. Any profile that slices against such valuesets will fail validation entirely because the slices can't resolve. You already yell when you validate the code itself and say you can't confirm it's correct. That provides the necessary 'protection' against possibly invalid codes.

you're not making any sense

all this question is about making an issue when validating value sets that the code system isn't known. Apparently letting people know this really makes you angry

I'm totally fine with a warning saying the code system isn't known. I'm not fine with not expanding value sets or validating value set membership just because the code system isn't known. What isn't making sense? That people will need tx servers to validate value sets when the tx server won't have access to a code system definition? That being able to validate code membership in a valueset is necessary to avoid slicing errors?

well, you can get as angry as you like about that, but I'm not changing that behaviour, and nor will the other terminology servers. Trying to use a value set against an unknown code system will result in errors. (at least, they've told me that)

Why? That makes the tx server useless unless a code system definition is known and there are lots of legitimate reasons why it can't be known.

so it's useless then. No code system, not service.

Why is it necessary to make that choice? The information exists to check that the code is within the value set. Whether the validity of the code itself can be checked is irrelevant unless you're worried about codes being retired - and there are lots of situations where they can't be or it doesn't matter. I could fully get behind raising a warning, but refusing to expand at all doesn't make sense. The current behavior means authors have to publish value set expansions with their value set so that the tx server isn't called - and that's pointless busy-work.

if you've looked at value sets out there, you'd understand that we're not worried about retirement. Oh no. People just make anything up. By mistake. or otherwise.

feel free to write your own server

btw the servers will also ignore the expansions mostly

So what if they do? They're not asking you to check if the codes are valid - that's a different call. They're asking to check if the code (made up or not) is in the value set. In policing bad behavior in the wrong place, you're preventing useful and necessary behavior. The validator will already say "I can't tell if this code is valid because I don't have access to the code system". Why refuse to expand the value set on top of that? You're not accomplishing a greater level of warning, you're just preventing validation at all.