Stream: IG creation
Topic: SCT value set warnings
Nathan Davis (Aug 06 2020 at 21:23):
I'm getting many warnings stating that the SNOMED codes I'm using are not valid in http://snomed.info/sct. I know that the codes are valid. How do I fix the warning? The IG is the Vital Signs IG http://build.fhir.org/ig/HL7/cimi-vital-signs/branches/master/index.html The qa output can be found at http://build.fhir.org/ig/HL7/cimi-vital-signs/branches/master/qa.html
Lloyd McKenzie (Aug 06 2020 at 21:49):
@Grahame Grieve
Grahame Grieve (Aug 06 2020 at 23:25):
@Nathan Davis the only warning I get is this one:
The code 24311000205101 is not valid in the system http://snomed.info/sct
This looks correct to me: I don't find 24311000205101 in the snomed browser
Nathan Davis (Aug 07 2020 at 13:53):
@Grahame Grieve Thank you!
Ted Klein (Aug 07 2020 at 14:09):
I an dead in the water here with publisher 1.1.9 now - was working same content with 1.1.5 - when it checks for supported code systems set it crashes: Terminology server: Check for supported code systems for http://snomed.info/sct (02:30.0230)
Publishing Content Failed: null (02:41.0454)
Was there a change and I have to put the cache file somewhere else, or declare something? @Grahame Grieve what changed and how can I get the UTG build working again now?
Rob Hausam (Aug 07 2020 at 14:47):
I'm getting the same error with 1.1.9:
Terminology server: Check for supported code systems for http://snomed.info/sct (02:42.0231)
Publishing Content Failed: null (02:55.0128)
(02:55.0129)
Use -? to get command line help (02:55.0129)
(02:55.0130)
Stack Dump (for debugging): (02:55.0130)
java.lang.NullPointerException
at org.hl7.fhir.validation.instance.type.ValueSetValidator.validateValueSetIncludeConcept(ValueSetValidator.java:149)
at org.hl7.fhir.validation.instance.type.ValueSetValidator.validateValueSetInclude(ValueSetValidator.java:106)
at org.hl7.fhir.validation.instance.type.ValueSetValidator.validateValueSetCompose(ValueSetValidator.java:65)
at org.hl7.fhir.validation.instance.type.ValueSetValidator.validateValueSet(ValueSetValidator.java:55)
at org.hl7.fhir.validation.instance.InstanceValidator.checkSpecials(InstanceValidator.java:3647)
at org.hl7.fhir.validation.instance.InstanceValidator.startInner(InstanceValidator.java:3619)
at org.hl7.fhir.validation.instance.InstanceValidator.start(InstanceValidator.java:3497)
at org.hl7.fhir.validation.instance.InstanceValidator.validateResource(InstanceValidator.java:4595)
at org.hl7.fhir.validation.instance.InstanceValidator.validate(InstanceValidator.java:685)
at org.hl7.fhir.validation.instance.InstanceValidator.validate(InstanceValidator.java:661)
at org.hl7.fhir.igtools.publisher.Publisher.validate(Publisher.java:4722)
at org.hl7.fhir.igtools.publisher.Publisher.validate(Publisher.java:3720)
at org.hl7.fhir.igtools.publisher.Publisher.loadConformance(Publisher.java:3701)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:854)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:715)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:7912)
Rob Hausam (Aug 07 2020 at 14:59):
Apparently it's a bug in the ValueSetValidator code. I think I see where the NPE is happening.
Rob Hausam (Aug 07 2020 at 15:12):
@Ted Klein It looks like that problem has been fixed in 1.1.10.
Ted Klein (Aug 07 2020 at 18:16):
OK let me install that one. Grahame told me early this morning I should be using 1.1.9
Last updated: Apr 12 2022 at 19:14 UTC