Stream: terminology
Topic: validate-code and versions
Michael Lawley (Nov 04 2019 at 02:17):
This is a follow-on from @Grahame Grieve 's comment here https://chat.fhir.org/#narrow/stream/179167-hapi/topic/Using.20ValueSet.2Ecompose.20instead.20of.20ValueSet.2Eexpansion/near/175383132
For a CodeSystem where concept permanence holds, how should $validate-code behave in the presence of code system versions?
Grahame Grieve (Nov 04 2019 at 09:22):
can you be more specific?
Michael Lawley (Nov 04 2019 at 14:08):
Some examples:
- Coding has version '3', but Tx server only knows about version '5'.
- Coding has version '4', but Tx server only knows about version '2'
- Coding has version '3', but Tx server only knows about versions '4' & '5', code was not defined in version '4', but is in '5'
- Coding has version '4', but Tx server only knows about version '2', display doesn't match the display in '2'
Michael Lawley (Nov 04 2019 at 14:10):
- Coding has version '4', but Tx server only knows about version '5', code was made inactive in '5' and 'replaced by' another code, 'B', 'B' is in the ValueSet
Lloyd McKenzie (Nov 04 2019 at 14:16):
Version labels won't necessarily have an order that is known to the terminology server, so cases 1 and 2 are likely to be indistinguishable.
Grahame Grieve (Nov 04 2019 at 19:39):
I don't think that we have a formal agreed answer to this question. It would ordinarirly be a question for the steward of the code system. Which is not the scope of your question, I understand.
Personally, for a code system with concept permanance, I'd us the latest version, and put a warning about that in the validation responses
Michael Lawley (Nov 04 2019 at 22:30):
Hmm, we're a little more conservative; if you specify a version then we go for a match. Otherwise we use the latest (if there's an ordering on the version strings)
Grahame Grieve (Nov 05 2019 at 03:49):
I can understand that. but I think in the end it 's a combination of steward and organization that decides
Last updated: Apr 12 2022 at 19:14 UTC
