View/Validate Questionnaire JSON

[JonZammit]

Hi everyone.

Just wondering if something has changed with View/Validate Questionnaire JSON? I am not able to validate SNOMED codes. Pretty sure this was working previously. Now I'm getting errors like this when validating against any server...

Error: Unable to validate code http://snomed.info/sct#281666001 - Code is not found in CodeSystem: http://snomed.info/sct

This is a valid code in SNOMED as you can see here:

https://snowstorm.snomedtools.org/fhir/CodeSystem/$validate-code?code=281666001&url=http://snomed.info/sct

Thank you for all your work on this project. This tool has been very useful!

[akanduru]

Hi,
Can you provide a sample questionnaire causing the error?

[plynchnlm]

I think for the validation of SNOMED codes to work, the terminology server needs to be set to https://snowstorm.ihtsdotools.org/fhir. Is it? (Look under "Advanced Fields" for that. It can be set either at the form level or the item/question level. Sometimes the formbuilder sets that for you.)

[JonZammit]

After some more testing, it looks like validation is successful when using the Ontoserver endpoint as the FHIR server to validate against. https://r4.ontoserver.csiro.au/fhir

This makes sense as Ontoserver is a FHIR server with SNOMED CT loaded while the others (https://hapi.fhir.org/baseR4 and https://lforms-fhir.nlm.nih.gov/baseR4) may not have SNOMED CT loaded at the moment?

Snowstorm is strictly a terminology server so I don't believe you could validate a questionnaire or QR against Snowstorm.

[plynchnlm]

I am glad you found a FHIR server that has SNOMED loaded. When I mentioned setting the terminology server, I was referring to the "preferred terminology server" extension, which goes on either an item or at the form level. However, it seems that HAPI FHIR does not pay attention to that extension when it does $validate, but tries to use its own knowledge of the terminology, which it is missing. It seems to me it should pay attention to that extension, and I will raise that issue, but any fix from that direction is likely to be a long time coming.

Maybe the formbuilder should detect the presence of SNOMED codes, and default its validation to a FHIR server that can handle that. As an FYI, though, as I recall, while SNOMED is recommended for answer lists, I think LOINC was recommended for question codes, in countries where LOINC has been adopted. (https://danielvreeman.com/blog/2015/11/07/guidelines-for-using-loinc-and-snomed-ct-together-without-overlap/, "LOINC provides codes that represent the names of information items (e.g. questions) and SNOMED CT provides codes that may represent nominal and ordinal values (e.g. answers) for these named information items.") You didn't mention where your SNOMED code was, and of course you are free to use what you want.

[JonZammit]

Thanks Paul.

I am familiar with the preferred terminology server (TS) settings you mentioned. I was under the impression that the TS options are used when the answers are defined using a value set. So it facilitates a query to $expand the value set. I also thought the functionality I was originally asking about performs a $validate questionnaire.

My experience is that is not necessary to set the TS option when using a "SNOMED answer value set" because the subsequent SNOMED settings provide a mechanism to query snowstorm.

However it is sometimes necessary when using the "Answer value set URI" option. For example, http://hl7.org/fhir/ValueSet/languages needs a TS defined, while http://hl7.org/fhir/ValueSet/administrative-gender does not. Interesting given that these are both HL7 value sets.

In my questionnaire, the SNOMED code that was failing validation set as a question code. As you mentioned, sometimes you might want to attach meaning to a question using a SNOMED or LOINC code, aka model meaning binding.

[JonZammit]

BTW when I say "necessary" above, I mean to allow proper previewing / rendering of the questionnaire.