FHIR: FHIR server $validate accepts resource json with duplicate keys

During initial PDM R6.0 testing, it was discovered that a FHIR $validate operation would return a NoError response for a resource with duplicate keys. This can be reproduced as follows:

url: https://us-south.wh-fhir.dev.cloud.ibm.com/wh-fhir-dev/api/v4//Condition/$validate

POST payload:

{
	"resourceType": "Condition",
	"subject": {
		"reference": "Patient/b589c393-4146-4fef-921d-3facbfbd3bd0"
	},
	"subject": {
		"reference": "Patient/e8f4d046-4eb5-4c9e-972a-fb02c5e4d5f4"
	}
}

Strictly speaking, the json spec allows duplicate keys. But many json editors and other tooling flag dup keys as an error. I then sent the above resource to the create API. The Condition was successfully created, with the second subject only.

I think it would be prudent for FHIR to detect duplicate keys on resources and return the appropriate failure responses on validate, create, update. Persisting data in the FHIR database that passed validation and yet is not a reflection of the data sent in by the user is misleading, IMHO.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 16 (7 by maintainers)

Commits related to this issue

Most upvoted comments

#After further research, I found that Jackson supports a configuration that will reject duplicate keys:

    @Test
    public void testDuplicateKeys2() throws Exception {
        try (InputStream in = DuplicateKeysTest.class.getClassLoader().getResourceAsStream("JSON/condition-duplicate-keys.json")) {
            ObjectMapper objectMapper = new ObjectMapper();
            objectMapper.enable(JsonParser.Feature.STRICT_DUPLICATE_DETECTION);
            JsonNode jsonNode = objectMapper.readValue(in, JsonNode.class);
            System.out.println(jsonNode);
        }
    }

Jackson also has compatibility with javax.json: https://github.com/FasterXML/jackson-datatypes-misc/tree/master/jsr-353

This module implements the javax.json object model on top of Jackson. I worked out a way that we could wire this up in the fhir-provider module. It fixes the original issue, but introduces a new issue related to BigDecimal precision. Precision in does not always equal precision out. In order to fix the precision issue, I would need to modify a source file coming from the Jackson project. This doesn’t seem like a viable solution. We have raised an issue with the jakarta-ee JSON-P project here:

https://github.com/eclipse-ee4j/jsonp/issues/240

They said that they would welcome a PR to fix the issue directly in their codebase.

+1
JohnTimm on May 29, 2020
Read more comments on GitHub
← linuxdeploy: linuxdeploy crashes on Ubuntu Xenial running with docker
FHIR: Postgres connection timeout →