FHIR Chat · JSON Validation · hapi

Stream: hapi

Topic: JSON Validation

Jenni Syed (Dec 16 2016 at 23:26):

I've been troubleshooting some places where our JSON seems to be parsing and validating, even though we don't think it should. Given this json:
{"resourceType": "Patient", "id": 123, "meta": { "versionId": "29", "lastUpdated": "2015-12-22T19:53:11.000Z" }, "communication": { "language": { "coding": [ { "system": "urn:ietf:bcp:47", "code": "hi", "display": "Hindi", "userSelected": false }], "text": "Hindi" }, "preferred": true } }

Jenni Syed (Dec 16 2016 at 23:27):

I would expect at least an error about the id not being a string, and the communication not being a list.

Josh Mandel (Dec 16 2016 at 23:27):

me too :-)

Jenni Syed (Dec 16 2016 at 23:28):

My context is set up with the StrictErrorHandler, and the SchemaBaseValidator and SchematronBaseValidator, and I've stepped into validation code and confirmed both end up in the validators list

Jenni Syed (Dec 16 2016 at 23:30):

I've tried a few ways to validate:

IBaseResource fakeresource = context.newJsonParser().parseResource(fakeBody); ValidationResult validationResult = validator.validateWithResult(fakeBody); ValidationResult otherResult = validator.validateWithResult(fakeresource);

Jenni Syed (Dec 16 2016 at 23:32):

All success/no issues. If I step through it, the JSON raw gets converted to XML. The XML ends up as:

<Patient xmlns="http://hl7.org/fhir">
<id value=“123"/>
<meta>
    <versionId value="29"/>
    <lastUpdated value="2015-12-22T19:53:11.000Z"/>
</meta>
<communication>
    <language>
        <coding>
            <system value="urn:ietf:bcp:47"/>
            <code value="hi"/>
            <display value="Hindi"/>
            <userSelected value="false"/>
        </coding>
        <text value="Hindi"/>
    </language>
    <preferred value="true"/>
</communication>
</Patient>

Jenni Syed (Dec 16 2016 at 23:33):

Which is, unfortunately for us, valid

Jenni Syed (Dec 16 2016 at 23:35):

I'm not sure if there's a better way for me to run this through validation and have it actually catch these? And is this just an expected result since the source is JSON? It feels like a bug, but I know the validation logic is relatively recent.

Jenni Syed (Dec 16 2016 at 23:39):

To make this more fun (and a warning to others): if you try to log the result of the client call (assuming it's in resource form and you call encodeResourceToString), the JSON will come back out valid since it starts from the resource. This makes sense, given that it's starting from the resource, but threw us for a loop since not only did the JSON parser not error, the JSON getting logged looked great :)

Grahame Grieve (Dec 17 2016 at 00:38):

@James Agnew the validator validates JSON/stream/byte[] directly now - no need to convert to XML

Grahame Grieve (Dec 17 2016 at 00:39):

I'll have to check whether the underlying validator is right on this one

James Agnew (Dec 19 2016 at 16:11):

@Jenni Syed How are you setting up the validator? (ie. which modules are you feeding it)?

If you're using the FhirInstanceValidator I would expect it to catch these issues. You'd need to do the following to register that validator if you haven't already:

FhirInstanceValidator instanceValidator = new FhirInstanceValidator();
validator.registerValidatorModule(instanceValidator);

If you're validating without that part, it's probably just running your JSON through the XSD validator and it does an automatic conversion to XML before proceeding with that.

I'm guessing this is related to your other question.. this gives me an idea. We have a server interceptor that automatically validates the raw request and response, but no such interceptor on the client. Sounds like that is exactly what you want really.

Jenni Syed (Dec 19 2016 at 16:17):

@James Agnew I was using the Schema/Schematron ones. I originally started this on an older version of HAPI, not sure if I saw the FHIRInstance option. I can try that out.

Jenni Syed (Dec 19 2016 at 16:19):

The interceptor would be nice, but the one line we have that is checking this isn't too cumbersome since we already do a lot with the requests/responses as is :)

Jenni Syed (Dec 19 2016 at 16:23):

hrm. Or I couldn't find it :) Having issues getting that class to resolve. I'll look around a bit.

James Agnew (Dec 19 2016 at 16:25):

If you're doing DSTU2, you need to add the hapi-fhir-structures-dstu2-hl7org dependency to your pom/project. The validator doesn't live in the same place as the DSTU2 structures in the pre-STU3 HAPI world..

Jenni Syed (Dec 19 2016 at 16:27):

which is different than hapi-fhir-structures-hl7org-dstu2?? or typo? (that's in the classpath)

James Agnew (Dec 19 2016 at 16:28):

oops, sorry that's just my typo.. you have the right one.

The class you're after is org.hl7.fhir.instance.hapi.validation.FhirInstanceValidator if that helps

Jenni Syed (Dec 19 2016 at 16:30):

How about org.hl7.fhir.instance.validation.InstanceValidator?

Jenni Syed (Dec 19 2016 at 16:30):

that's all I see in that jar, that's similar :)

Jenni Syed (Dec 19 2016 at 16:31):

well, at least I thought

James Agnew (Dec 19 2016 at 16:32):

Weeeeeird. You aren't on a super-old version of that JAR are you? Maven sees it in there as of 1.4:

http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.hl7.fhir.instance.hapi.validation.FhirInstanceValidator%22

Jenni Syed (Dec 19 2016 at 16:33):

I think something is funky with my IDE-created classpath... let me play a bit with the maven resolution

Jenni Syed (Dec 19 2016 at 16:34):

It *thinks* i'm on 2.1, but it doesn't see that class

Jenni Syed (Dec 19 2016 at 16:39):

Ok, forced it to regenerate the classpath... seems to be finding it now, and I can see it.
Do the schema/schematron validators do anything for me that the FHIRInstance one won't do?

Jenni Syed (Dec 19 2016 at 16:43):

I'm not getting errors with the FHIRInstanceValidator either, going to try cutting it back down to a smaller test case again

James Agnew (Dec 19 2016 at 16:57):

Hmm, let me try plugging your example into a test case.

Jenni Syed (Dec 19 2016 at 16:57):

It looks like it's a warning/info. Though not seeing anything for the id

James Agnew (Dec 19 2016 at 17:02):

Hmm.. Yeah, I don't even see any relevant errors in the validator output. Weird. Let me dig into it...

12:00:17.288 [main] INFO  c.u.f.v.FhirInstanceValidatorTest [FhirInstanceValidatorTest.java:172] - Result 0: INFORMATION - /communication/language - Binding by URI reference cannot be checked
12:00:17.289 [main] INFO  c.u.f.v.FhirInstanceValidatorTest [FhirInstanceValidatorTest.java:172] - Result 1: INFORMATION - /communication/language/coding - Binding for path /communication/language/coding has no source, so can't be checked

James Agnew (Dec 19 2016 at 17:15):

Hmm, yeah. It seems like the DSTU2 validator doesn't catch either of these issues. Interestingly the STU3 validator catches the numeric ID but not the array one:

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "processing",
      "diagnostics": "Error parsing JSON: the primitive value must be a string",
      "location": [
        "/Patient/id"
      ]
    },
    {
      "severity": "warning",
      "code": "processing",
      "diagnostics": "None of the codes provided are in the value set http://hl7.org/fhir/ValueSet/languages (http://hl7.org/fhir/ValueSet/languages, and a code should come from this value set unless it has no suitable code) (codes = urn:ietf:bcp:47#hi)",
      "location": [
        "Patient.communication.language"
      ]
    }
  ]
}

Jenni Syed (Dec 19 2016 at 17:26):

It also doesn't seem to like hi for hindi in STU3?

James Agnew (Dec 19 2016 at 17:27):

Yeah, there's no built-in BCP47 validator yet... Not sure why that's the error message it gives for that.

As a short-term fix, I'm just looking at cleaning up the JsonParser so that StrictErrorHandler will alos fail for these issues. It really should.

James Agnew (Dec 19 2016 at 17:28):

I have a unit test for this now too, so I can dig into why the instancevalidator isn't catching this stuff at some point..

Grahame Grieve (Dec 19 2016 at 19:28):

@Jenni Syed in STU3, there's nothing that schema/schematron test that isn't tested by the validator

Jenni Syed (Dec 19 2016 at 19:28):

What about DSTU2 (which is where I am right now)

Grahame Grieve (Dec 19 2016 at 19:30):

I can't remember when I started validating order in the instance validator

Grahame Grieve (Dec 19 2016 at 19:32):

looks like the DSTU2 validator does not check order; it assumes that schema is used for that

Jenni Syed (Dec 19 2016 at 20:24):

The errors for "has no source, so cannot be checked" - is that an error related to HAPI not knowing the system being returned? IE: its binding in core FHIR isn't required?

It seems that way, looking through some of the code. EG: https://github.com/jamesagnew/hapi-fhir/blob/191e3b6d4d29fd36c35bc8f0b5d9c08f8ce618a3/hapi-fhir-structures-dstu3/src/main/java/org/hl7/fhir/dstu3/validation/InstanceValidator.java#L666

Jenni Syed (Dec 19 2016 at 20:26):

er, no, marital status seems to be required but getting that error. So then - HAPI just doesn't know it?

Jenni Syed (Dec 19 2016 at 20:40):

I think I have something else wrong in my config... I see some of these valuesets defined, and the codes for them, in the XML files. On to more troubleshooting! :)

James Agnew (Dec 20 2016 at 14:15):

This just appears to be a bug in the DSTU2 validator (which is already fixed in the STU3 one). I'm fixing it now.

Man, I'm really excited to see Grahame's "validate DSTU2 resources using the DSTU3 validator" module. Having one validator codebase is going to be awesome!

James Agnew (Dec 20 2016 at 14:30):

Argh, that "has no source" is a pain. I don't think it's going to get fixed now after all.. Presumably this would require a bunch of work, and it's probably not worth the effort since we're about to swap out the validator anyhow (and the message is just an INFO one, not an actual error).

Basically the validator sees the binding on Patient.maritalStatus but doesn't see it when it goes to validator Patient.maritcalStatus.coding. So the codes do get validated, you just get a spurious info message.

Jenni Syed (Dec 20 2016 at 15:42):

@James Agnew Thanks :) Now I just have to figure out how to ignore that one (and other similar ones that I think are "fake") but still get the errors for the communication issue...

Jenni Syed (Dec 20 2016 at 15:44):

Is there a way to use the new single code base yet, or is that still pending release (and when?? :) )?

James Agnew (Dec 20 2016 at 16:08):

Grahame's got it in the RI codebase, so you could certainly pull that into your project... My aim is to release HAPI 2.2 today, and start working on getting the joined validator into the next snapshot building within a week or so, if that helps

Jenni Syed (Dec 20 2016 at 16:19):

That will help - I'll watch for the newer snapshots and versions so we can upgrade

Last updated: Apr 12 2022 at 19:14 UTC