Stream: conformance
Topic: Validator failure for own ValueSet defintion with SNOMED CT
Oliver Egger (Dec 11 2019 at 09:20):
We define ValueSets which contain a finite list of SNOMED CT codes and and additional codes from an other CodeSystem. We defined them via compose even though it is a list of fixed codes because we have designations for the different languages. We bind this ValueSet to a profiled DocumentReference (see example).
The Java Validator/IG Publisher fails for this examples with the message:
None of the codes provided are in the value set http://fhir.ch/ig/ch-epr-term/ValueSet/DocumentEntry.typeCode (http://fhir.ch/ig/ch-epr-term/ValueSet/DocumentEntry.typeCode, and a code from this value set is required) (codes = http://snomed.info/sct#371532007)
A first analysis revealed that the Validator does not validate the code locally with the provided ValueSet because the code is from SNOMED CT which is not a complete CodeSystem. In the next step the Validator then sends the ValueSet together with the code to tx.fhir.org. This fails now because the second code system is not known to tx.fhir.org (it is defined currently only in our implementation guide).
This leads to three questions I would happy to get some feedback:
- is our approach correct with defining ValueSets with compose or should we provide already expanded ValueSets in our Implementation Guide?
- could the validation logic be extend, that if a code can be validated within a ValueSet event though it is not a complete CodeSystem so that the code does not need to be validated with tx.fhir.org? (This would not work in all cases would be more an optimization)? if yes, we would start to work on a pull request
- can also a local code system be supplied to tx.fhir.org (inlined in the ValueSet)?
Grahame Grieve (Dec 11 2019 at 10:48):
your approach is fine. can we turn this into a concise test case?
Grahame Grieve (Dec 11 2019 at 10:50):
though when I look at your value sets.. that's not how snomed extensions work...
Oliver Egger (Dec 11 2019 at 10:58):
though when I look at your value sets.. that's not how snomed extensions work...
thanks, this needs to be addressed by our snomed national release center, they have just started the process, I will put it on the agenda, i see them this afternoon
Oliver Egger (Dec 11 2019 at 11:02):
your approach is fine. can we turn this into a concise test case?
leaving the snomed extension discussion aside, where would be the place to start with testcases for validator/terminology server? fhir-test-cases/validator?
Grahame Grieve (Dec 11 2019 at 11:03):
yes. but this time I've added it - your profiles etc were nice and small
Grahame Grieve (Dec 11 2019 at 11:48):
I think that the right approach s that L349 and L72 of ValueSetCheckerSImple, instead of throwing an exception when the code system is not supported, that's when you consult the terminology server, for just that include. it happens elsewhere like that, so not sure why not here
Grahame Grieve (Dec 12 2019 at 00:09):
ok this should be fixed now
Oliver Egger (Dec 12 2019 at 09:09):
confirmed, thanks a lot @Grahame Grieve
Grahame Grieve (Dec 12 2019 at 09:10):
glad I can fix something
Oliver Egger (Dec 12 2019 at 09:17):
though when I look at your value sets.. that's not how snomed extensions work...
thanks, this needs to be addressed by our snomed national release center, they have just started the process, I will put it on the agenda, i see them this afternoon
they are aware of the situation, next spring a snomed ct swiss edition is planned where the codes are included.
Kevin Mayfield (Dec 12 2019 at 09:24):
This leads to three questions I would happy to get some feedback: - is our approach correct with defining ValueSets with compose or should we provide already expanded ValueSets in our Implementation Guide?
I've gone with 'already expanded valueSets' to get around ecl issues. Wondering if this is correct?
Grahame Grieve (Dec 12 2019 at 10:16):
well, there's no fixed answer to this. In general, it's better to distribute the formal definition of the value set, rather than a particular expansion that's correct under your conditions at a given time. that way, people can generate a correct expansion locally given their own conditions. Does that matter...? depends how tightly you control the conditions. But my general observation is that the distributors always think they have better control than they do.
OTOH, distributing the formal definition rather than the expansion assumes that everyone can correctly evaluate the definition. Which my server can't right now...
Last updated: Apr 12 2022 at 19:14 UTC
