Stream: implementers
Topic: validating resources against StructureDefinition
Venkat Reddy (Sep 15 2016 at 18:17):
Hi All, this is regarding to validateWithResult() method. it is performance hit. tried with Patient resource and default profile. is there any other alternative to it. suggestions will be helpful.
Lloyd McKenzie (Sep 15 2016 at 19:09):
You're using the reference implementation? A good bit of the performance is in the terminology services invocations - if you can cache that, it's less of an issue. Also, the validator hasn't really been performance tuned. As well, there's a trade-off between validation thoroughness and performance - the more you validate, the more time it will take
Venkat Reddy (Sep 15 2016 at 19:32):
@Lloyd McKenzie Any link / document reference to configure the validation thoroughness .
Lloyd McKenzie (Sep 15 2016 at 19:42):
Well, there's an ability to turn off external terminology validation - just specify your terminology server as "na". Beyond that, the configuration mechanism is "wade through the code and remove/comment out what you wish". The focus of the validator to date has been meeting the needs of the FHIR publishing process, not run-time use, so we haven't profiled it to see where the performance issues are, nor figured out where we can tune those vs. where it makes sense to make those portions of the validation configurable. (And realistically, this work is likely to happen as part of paid project work rather than standard volunteer effort.)
Grahame Grieve (Sep 16 2016 at 10:11):
where is validateWithResult()? what code are you referring to?
Grahame Grieve (Sep 16 2016 at 10:11):
and how long is it taking?
Łukasz Kułakowski (Oct 06 2021 at 18:36):
Hello everyone,
I'll pin my question under current topic as it fits perfectly :)
I've been trying to build FHIR resource validator in python, basing only on StructureDefiniton.differential.element (assuming that we have basic validation of resource already in place) and I've been wondering if there is any more efficient method of validating a resource than looping through each StructureDefinition.differential.element? Just want to make sure I'm following the docs correctly, I've generated my StructureDefinition's using Forge and I see that all the information that I want to validate against are actually included in StructureDefinition.differential.element so naturally I wanted to build test cases around those, but maybe im missing somethin.
Thanks!
Lloyd McKenzie (Oct 06 2021 at 18:53):
You definitely want to perform validation using snapshot, not differential. The algorithm for generating a snapshot from a differential is super-complex and you definitely don't want to take that on in addition to doing the validation piece.
Vivek S (Oct 07 2021 at 09:11):
Hi,
I am using validator_cli.jar to validate the FHIR resource against my profiles/ig. I am seeing an error as below for one of the Observation.code.
As per the understanding, this snomed code "459231000124102" is available in "http://snomed.info/sct/900000000000207008/version/20210731" version. However the validator is pointing to "http://snomed.info/sct/900000000000207008/version/20200131" version as seen in the error.
Error @ Observation.code.coding[0] (line 23, col8) : Unable to find code 459231000124102 in http://snomed.info/sct (version http://snomed.info/sct/900000000000207008/version/20200131); The code "459231000124102" is not valid in the system http://snomed.info/sct; The code provided (http://snomed.info/sct#459231000124102) is not valid in the value set 'All codes known to the system' (from http://tx.fhir.org/r4) for 'http://snomed.info/sct#459231000124102'
Even though I pass the specific version in FHIR resource as below, validator is trying to refer "20200131" version and return the above error .
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/900000000000207008/version/20210731",
"code": "459231000124102",
"display": "Sequential organ failure assessment score (assessment scale)"
}
]
}
Any thoughts on how to resolve this specific version issue seen in validator is appreciated.
Lloyd McKenzie (Oct 07 2021 at 13:22):
@Rob Hausam
Rob Hausam (Oct 07 2021 at 13:46):
@Vivek S I'll try to take a look at this. If you don't hear from me on it today, feel free to ping again (or PM me directly).
David Simons (Oct 12 2021 at 09:43):
this is esp. surprising, since via the web interface the concept _is_ found: http://tx.fhir.org/snomed/900000000000207008-20210731/?srch=459231000124102- when the version is correctly used. (the concept did not yet exist in 20200131)
somehow the hl7validator+tx.fhir.org do not take the supplied version in to account, when using the FHIR-REST API ($validate)
@Grahame Grieve @Rob Hausam it is very well possible that the hl7validator does not pass the version along in its call - 20210731is not found in the txLog file.... the version seems missing on the POST http://tx.fhir.org/r4/CodeSystem/$validate-code? HTTP/1.0:
<?xml version="1.0" encoding="UTF-8"?>
<Parameters xmlns="http://hl7.org/fhir">
<parameter>
<name value="coding"/>
<valueCoding>
<system value="http://snomed.info/sct"/>
<code value="459231000124102"/>
<display value="Sequential organ failure assessment score (assessment scale)"/>
</valueCoding>
</parameter>
<parameter>
<name value="profile"/>
<resource>
<Parameters>
<parameter>
<name value="profile-url"/>
<valueString value="http://hl7.org/fhir/ExpansionProfile/dc8fd4bc-091a-424a-8a3b-6198ef146891"/>
</parameter>
<parameter>
<name value="system-version"/>
<valueString value="http://snomed.info/sct|http://snomed.info/sct/900000000000207008"/>
</parameter>
</Parameters>
</resource>
</parameter>
</Parameters>
with the following response (note the tx server using its default version):
<?xml version="1.0" encoding="UTF-8"?>
<Parameters xmlns="http://hl7.org/fhir">
<parameter>
<name value="result"/>
<valueBoolean value="false"/>
</parameter>
<parameter>
<name value="message"/>
<valueString value="Unable to find code 459231000124102 in http://snomed.info/sct (version http://snomed.info/sct/900000000000207008/version/20200131); The code "459231000124102" is not valid in the system http://snomed.info/sct; The code provided (http://snomed.info/sct#459231000124102) is not valid in the value set 'All codes known to the system'"/>
</parameter>
<parameter>
<name value="cause"/>
<valueString value="invalid"/>
</parameter>
</Parameters>
Łukasz Kułakowski (Oct 12 2021 at 12:46):
When dealing with validation of resource using StructureDefinitions, how do you store information about which StructureDefinition should be used to validate which resource? E.g. I have several observation resources like heart rate, saturation etc and I'd like to validate them with different StructureDefinitions, should information about which SD to use be stored inside resource, or should i dynamically assign the proper structure basing on "category" or "code"?
David Simons (Oct 12 2021 at 13:23):
Łukasz Kułakowski said:
When dealing with validation of resource using StructureDefinitions, how do you store information about which StructureDefinition should be used to validate which resource? E.g. I have several observation resources like heart rate, saturation etc and I'd like to validate them with different StructureDefinitions, should information about which SD to use be stored inside resource, or should i dynamically assign the proper structure basing on "category" or "code"?
ah, the original topic - we hijacked it - :) the quick answer is to claim 1..* SD/profile conformance(s) using meta.profile (https://www.hl7.org/fhir/resource.html#Meta) in the Resource.
Łukasz Kułakowski (Oct 12 2021 at 14:05):
Thanks @David Simons !
Grahame Grieve (Oct 18 2021 at 03:49):
hmm. I found and fixed a nmber of issues related to this but I couldn't actually reproduce this, so I'm not sure I fixed it. How would I reproduce this?
Vivek S (Oct 19 2021 at 03:50):
Grahame Grieve said:
hmm. I found and fixed a nmber of issues related to this but I couldn't actually reproduce this, so I'm not sure I fixed it. How would I reproduce this?
Hi Grahame,
If the observation resource has below specified code, the FHIR validator used to return a Failure/Error indicating the the code is not valid in the system. Detailed error in my original post above. (code was valid only latest 20210731 SNOMED version, validator was referring 20200131 SNOMED version)
Post fix, we do not expect the FHIR validator to return the failure.
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/900000000000207008/version/20210731",
"code": "459231000124102",
"display": "Sequential organ failure assessment score (assessment scale)"
}
]
}
Vivek S (Oct 20 2021 at 10:19):
Grahame Grieve said:
hmm. I found and fixed a nmber of issues related to this but I couldn't actually reproduce this, so I'm not sure I fixed it. How would I reproduce this?
Hi Grahame, Could you please confirm if the changes are already merged to master branch for us to re-test?
Grahame Grieve (Oct 20 2021 at 10:48):
not in master. you can look at this PR:
Grahame Grieve (Oct 20 2021 at 10:48):
https://github.com/hapifhir/org.hl7.fhir.core/pull/624
David Simons (Oct 20 2021 at 13:18):
Grahame Grieve said:
not in master. you can look at this PR:
thanks, building this branch for @Vivek S, so we can test
David Simons (Oct 20 2021 at 14:44):
Thanks @Grahame Grieve, the hl7validator side seems to have been resolved with that PR #624, the version is now included in the POST
<?xml version="1.0" encoding="UTF-8"?>
<Parameters xmlns="http://hl7.org/fhir">
<parameter>
<name value="coding"/>
<valueCoding>
<system value="http://snomed.info/sct"/>
<version value="http://snomed.info/sct/900000000000207008/version/20210731"/>
<code value="459231000124102"/>
<display value="Sequential organ failure assessment score (assessment scale)"/>
</valueCoding>
</parameter>
David Simons (Oct 20 2021 at 14:48):
HOWEVER, the tx.fhir.org server side now seems to have lost the SNOMED 20210731 International version?
http://tx.fhir.org/snomed/900000000000207008-20210731/?srch=459231000124102 gives a Document /snomed/900000000000207008-20210731/ not found...
Also https://tx.fhir.org /snomed is gone
@Rob Hausam @Grahame Grieve
Rob Hausam (Oct 20 2021 at 15:00):
@David Simons It certainly should not have lost it. The server is running and the 20210731 International Edition appears to be loaded and is still showing as the default. But I agree that something seems wrong with the queries that I'm trying. I'll look at it further, but I'm occupied for the next hour.
David Simons (Oct 20 2021 at 15:06):
Rob Hausam said:
David Simons It certainly should not have lost it. The server is running and the 20210731 International Edition appears to be loaded and is still showing as the default. But I agree that something seems wrong with the queries that I'm trying. I'll look at it further, but I'm occupied for the next hour.
Thank you for all your support! End-of-day here - we'll check back in tomorrow.
David Simons (Oct 20 2021 at 15:08):
this is what we see currently, as additional input.
David Simons (Oct 21 2021 at 08:23):
Resolved
Vivek S (Oct 21 2021 at 08:28):
David Simons said:
Rob Hausam said:
David Simons It certainly should not have lost it. The server is running and the 20210731 International Edition appears to be loaded and is still showing as the default. But I agree that something seems wrong with the queries that I'm trying. I'll look at it further, but I'm occupied for the next hour.
Thank you for all your support! End-of-day here - we'll check back in tomorrow.
@Rob Hausam @Grahame Grieve Today we could see "http://tx.fhir.org/snomed/" up with "20210731" SNOMED version in it.
Also, I could re-test the validator for SNOMED code "459231000124102" against "20210731" SNOMED version on the latest changes created on PR #624, our tests now pass.
Thanks for the support.
Mike Ross (Jan 19 2022 at 19:01):
I am trying to validate a patient resource against the US-core profile using 5.6.2 HAPI libraries and loading the StructuredDefinition-us-core-patient.json resource from (http://hl7.org/fhir/us/core/STU4/full-ig.zip). Validating with an R4 FhirContext and using setDefaultTypeForProfile(), everything loads and validates as expected.
When I run my same test with a DSTU3 FhirContext I get a null pointer exception in the InstanceValidator. I have tried both the StructuredDefinition above and using the older DSTU3 StructuredDefinition (http://hl7.org/fhir/us/core/STU3.1.1/full-ig.zip). I am specifying the DSTU3 Patient class for the defaultType.
Is there a trick to validing DSTU3 resources with the current InstanceValidator? It looks like it is referencing R5 Element definitions. Any help appreciated.
Here is the stack trace:
java.lang.NullPointerException
at org.hl7.fhir.r5.model.Element.getExtensionString(Element.java:428)
at org.hl7.fhir.r5.model.ElementDefinition$TypeRefComponent.getWorkingCode(ElementDefinition.java:2264)
at org.hl7.fhir.validation.instance.InstanceValidator.checkChildByDefinition(InstanceValidator.java:4510)
at org.hl7.fhir.validation.instance.InstanceValidator.checkChild(InstanceValidator.java:4492)
at org.hl7.fhir.validation.instance.InstanceValidator.validateElement(InstanceValidator.java:4444)
at org.hl7.fhir.validation.instance.InstanceValidator.startInner(InstanceValidator.java:4160)
at org.hl7.fhir.validation.instance.InstanceValidator.start(InstanceValidator.java:4023)
at org.hl7.fhir.validation.instance.InstanceValidator.validateResource(InstanceValidator.java:5242)
at org.hl7.fhir.validation.instance.InstanceValidator.validate(InstanceValidator.java:748)
at org.hl7.fhir.validation.instance.InstanceValidator.validate(InstanceValidator.java:593)
at org.hl7.fhir.common.hapi.validation.validator.ValidatorWrapper.validate(ValidatorWrapper.java:181)
at org.hl7.fhir.common.hapi.validation.validator.FhirInstanceValidator.validate(FhirInstanceValidator.java:235)
at org.hl7.fhir.common.hapi.validation.validator.BaseValidatorBridge.doValidate(BaseValidatorBridge.java:22)
at org.hl7.fhir.common.hapi.validation.validator.BaseValidatorBridge.validateResource(BaseValidatorBridge.java:45)
at org.hl7.fhir.common.hapi.validation.validator.FhirInstanceValidator.validateResource(FhirInstanceValidator.java:25)
at ca.uhn.fhir.validation.FhirValidator.validateWithResult(FhirValidator.java:261)
at ca.uhn.fhir.validation.FhirValidator.validateWithResult(FhirValidator.java:202)
at com.qvera.qie.hapi.AbstractValidatorTest.testCustomProfileValidator(AbstractValidatorTest.java:101)
Eric Haas (Jan 19 2022 at 19:37):
US Core 3.1.1 is based on FHIR R4, The last published version of US Core based on FHIR STU3 is 2.0.0
Mike Ross (Jan 19 2022 at 21:51):
Thank you. I assumed it was the same versioning. I didn't realize that. I just tried the StructuredDefinition-us-core-patient.json from http://hl7.org/fhir/us/core/STU2/full-ig.zip, and I'm still getting the same null pointer as I try to use the validator for DSTU3 context.
If I remove the use of prePopulatedSupport from the chain, it reports that us-core-patient is unknown. When I include it in the change for DSTU3 FhirContext, it produces the null pointer exception in the InstanceValidator
PrePopulatedValidationSupport prePopulatedSupport = new PrePopulatedValidationSupport(context);
prePopulatedSupport.addStructureDefinition(usCoreStructureDefinition);
// https://hapifhir.io/hapi-fhir/docs/validation/validation_support_modules.html
// Create a chain that will hold our modules
ValidationSupportChain supportChain = new ValidationSupportChain(
defaultSupport
,commonCodeSystemsTerminologySupport
,inMemoryTerminologySupport
,prePopulatedSupport
);
// Wrap the chain in a cache to improve performance
CachingValidationSupport cache = new CachingValidationSupport(supportChain);
// Create a validator using the FhirInstanceValidator module. We can use this
// validator to perform validation
FhirInstanceValidator validatorModule = new FhirInstanceValidator(cache);
FhirValidator validator = context.newValidator().registerValidatorModule(validatorModule);
String patientString = createUSCorePatientString();
ValidationResult usCoreValidationResults = validator.validateWithResult(patientString);
Mike Ross (Jan 20 2022 at 16:42):
Thank you, Eric. It looks like it is working with the 2.0.0 IG.
Last updated: Apr 12 2022 at 19:14 UTC
