Stream: implementers
Topic: why does this $validate fail?
Job Schipper (May 11 2020 at 16:06):
Hi,
I've been trying to find out why I'm getting a validation error when validating the following resource:
curl -X POST \
'http://hapi.fhir.org/baseDstu3/Patient/$validate' \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-d '{
"resourceType": "Patient",
"meta": {
"profile": [
"http://fhir.nl/fhir/StructureDefinition/nl-core-patient"
]
},
"address": [
{
"_use": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/iso21090-AD-use",
"valueCode": "PHYS"
}
]
}
}
]
}'
It produces the error:
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/StructureDefinition/iso21090-AD-use is not allowed to be used at this point (allowed = e:Address; this element is [[Patient.address.use, Address.use, code])",
"location": [
"Patient.address[0].use",
"Line 11, Col 31"
]
}
The profile that is used can be found here: https://simplifier.net/NictizSTU3-Zib2017/nl-core-patient/~overview
As far as I can tell, the extension should be applied to address.use. What am I missing here?
James Agnew (May 11 2020 at 18:39):
Looking at the source for that extension: http://hl7.org/fhir/extension-iso21090-ad-use.json.html
It looks like the context is just "address", not "address.use". So presumably you need to move it up one level.
Josh Mandel (May 11 2020 at 21:50):
- Plus 5 bonus points for providing a short, complete, executable example with your question, and for stating your expectations vs observed behavior :)
Job Schipper (May 12 2020 at 06:27):
Thanks guys! I'll try moving it to the address element instead.
Does this mean that they documented it wrongly at https://simplifier.net/NictizSTU3-Zib2017/nl-core-address ? When you look at the field list there, the extension is shown within the extensions of the "use" field.
Job Schipper (May 12 2020 at 07:18):
I'm not sure why this is so confusing to me, but i'm running into a similar issue while trying to validate an extension on address.country:
curl -X POST \
'http://hapi.fhir.org/baseDstu3/Patient/$validate' \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-d '{
"resourceType": "Patient",
"meta": {
"profile": [
"http://fhir.nl/fhir/StructureDefinition/nl-core-patient"
]
},
"address": [
{
"_country": {
"extension": [
{
"url": "http://nictiz.nl/fhir/StructureDefinition/code-specification",
"valueCodeableConcept": {
"coding": [
{
"code": "NL",
"system": "urn:iso:std:iso:3166"
}
]
}
}
]
}
}
]
}'
this produces the errors:
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://nictiz.nl/fhir/StructureDefinition/code-specification is not allowed to be used at this point (allowed = e:CodeableConcept, e:code, e:Coding; this element is [[Patient.address.country, Address.country, string])",
"location": [
"Patient.address[0].country",
"Line 12, Col 31"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "Profile http://fhir.nl/fhir/StructureDefinition/nl-core-address, Element matches more than one slice - LandGBACodelijst, LandISOCodelijst",
"location": [
"Patient.address[0].country.extension[0]",
"Line 13, Col 22"
]
},
{
"severity": "warning",
"code": "processing",
"diagnostics": "None of the codes provided are in the value set http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.5.1--20171231000000 (http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.5.1--20171231000000, and a code should come from this value set unless it has no suitable code) (codes = urn:iso:std:iso:3166#NL)",
"location": [
"Patient.address[0].country.extension[0].value.ofType(CodeableConcept)",
"Line 16, Col 40"
]
}
]
The profile used is this: https://simplifier.net/NictizSTU3-Zib2017/nl-core-patient/~overview
I looked at the context of the extension (https://simplifier.net/NictizSTU3-Zib2017/Zibextensioncodespecification/~json) and one of the options is "Address.country", which I think I am using, so I don't expect to get the first error.
The second error seems to be about country having 2 extensions with the same URL in the profile. What should I do to distinguish which one I am using?
Job Schipper (May 12 2020 at 12:46):
@James Agnew any idea?
Grahame Grieve (May 12 2020 at 12:56):
Does this mean that they documented it wrongly
looks like it to me, yes
Grahame Grieve (May 12 2020 at 12:57):
The extension http://nictiz.nl/fhir/StructureDefinition/code-specification is not allowed to be used at this point (allowed = e:CodeableConcept, e:code, e:Coding; this element is [[Patient.address.country, Address.country, string])
looks like a bug to me.
Job Schipper (May 12 2020 at 13:12):
@Grahame Grieve you mean a bug in how that HAPI server handles the validation?
Grahame Grieve (May 12 2020 at 13:13):
a bug in the validator, yes. I've added a test case taken from your post to the validator test cases ,but I can't run the test cases right now. Working on it
Job Schipper (May 12 2020 at 13:22):
ok thanks!
Grahame Grieve (May 12 2020 at 22:55):
ok back to this. Here's quoting from the NL profile:
{
"id":"Address.country.extension",
"path":"Address.country.extension",
"slicing":{
"discriminator": [
{
"type":"value",
"path":"url"
},
{
"type":"value",
"path":"value.coding.system"
}
],
"rules":"open"
}
},
ok, so the extension is sliced by url and code system.
then 2 slices:
{
"id":"Address.country.extension:LandGBACodelijst",
"path":"Address.country.extension",
"sliceName":"LandGBACodelijst",
"short":"LandGBACode",
"max":"1",
"type": [
{
"code":"Extension",
"profile":"http://nictiz.nl/fhir/StructureDefinition/code-specification"
}
]
},
{
"id":"Address.country.extension:LandGBACodelijst.valueCodeableConcept:valueCodeableConcept",
"path":"Address.country.extension.valueCodeableConcept",
"sliceName":"valueCodeableConcept",
"binding":{
"strength":"extensible",
"description":"LandGBACodelijst",
"valueSetReference":{
"reference":"http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.5.1--20171231000000",
"display":"LandGBACodelijst"
}
}
},
{
"id":"Address.country.extension:LandISOCodelijst",
"path":"Address.country.extension",
"sliceName":"LandISOCodelijst",
"short":"LandISOCode",
"max":"1",
"type": [
{
"code":"Extension",
"profile":"http://nictiz.nl/fhir/StructureDefinition/code-specification"
}
]
},
{
"id":"Address.country.extension:LandISOCodelijst.valueCodeableConcept:valueCodeableConcept",
"path":"Address.country.extension.valueCodeableConcept",
"sliceName":"valueCodeableConcept",
"binding":{
"strength":"extensible",
"description":"LandISOCodelijst",
"valueSetReference":{
"reference":"http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.5.2--20171231000000",
"display":"LandISOCodelijst"
}
}
}
Grahame Grieve (May 12 2020 at 22:56):
The validator doesn't know what to do with this - no value is provided for the identified fixed value element value.coding.system, so it can't differentiate the extension between the 2 slices.
Grahame Grieve (May 12 2020 at 22:56):
@Alexander Henket fyi
Alexander Henket (May 13 2020 at 05:32):
Job reached out yesterday directly too. Didn’t know this was on zulip as well. @Ardon Toonstra created a ticket and we will fix the country extension slicing. We are bitten by lots of places where we needed slicing by valueset over the years and found a wrong way how to. This is one of first we ever made in HL7 NL
Alexander Henket (May 13 2020 at 07:55):
@Job Schipper just in case you want to test the proposed update to the profile: https://bits.nictiz.nl/browse/MM-1155
I've attached the update profile-to-be. FHIR IG Publisher Version 1.0.94-SNAPSHOT validates using this updated profile.
Alexander Henket (May 13 2020 at 07:59):
At this point it is not certain yet if it makes the May 2020 updates. Deadline officially already passed. In that case it will make the next update (September/October latest)
Alexander Henket (May 13 2020 at 08:32):
@Grahame Grieve I've been testing this a bit further. Seems we don't need the explicit patternCodeableConcept. Just the pattern slice definition will do.
However I'm getting unexpected feedback in qa when the extension/@url matches but the value.coding.system does not. Because of of the pattern I would have expected something on having 'element does not match any known slice', but instead I get 'code system uri is unknown'. Is my expectation wrong or does the validator need an update here?
<!-- definition -->
<element id="Address.country.extension">
<path value="Address.country.extension" />
<slicing>
<discriminator>
<type value="value" />
<path value="url" />
</discriminator>
<discriminator>
<type value="pattern" />
<path value="$this.value" />
</discriminator>
<rules value="open" />
</slicing>
</element>
<!-- Undefined extension slice, the url matches, but the system does
not match any defined value set -->
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="urn:oid:2.16.840.1.113883.2.4.4.16.35"/>
<code value="6030"/>
<display value="Nederland"/>
</coding>
</valueCodeableConcept>
</extension>
Grahame Grieve (May 13 2020 at 08:37):
is the code system actually known? That would be entirely separate to the slicing
Alexander Henket (May 13 2020 at 08:51):
The code system as stated in the instance is unknown to the IG Publisher. My intention was to test slice recognition, but indeed flagging if a detected code system exists is a secondary issue
Grahame Grieve (May 13 2020 at 08:51):
so then I'm not sure what the issue is
Alexander Henket (May 13 2020 at 08:53):
- The instance contains a fragment that does not match any of the defined slices -- this is not flagged in qa. I'm thinking it should have been
- The code system urn:oid:2.16.840.1.113883.2.4.4.16.35 is unknown -- this is flagged in qa
Alexander Henket (May 13 2020 at 08:55):
If I add an extension with a different url, it is flagged as unmatched slice. This fragment matches url, but not code system. It should still produce an 'unmatched' error in my mind
Grahame Grieve (May 13 2020 at 08:55):
well, I'll have to debug - can you send me a whole example + profile?
Alexander Henket (May 13 2020 at 08:56):
Sure... will take me a few moments... I'll DM you the zip
Job Schipper (May 14 2020 at 09:40):
@Alexander Henket @Grahame Grieve thanks for looking into this! We will try out the profile-to-be in the meantime until the change gets released.
Alexander Henket (May 14 2020 at 09:44):
The current profile-to-be assumes 2 code-specification extension each with its own valueset binding (ISO or GBA). Grahame made me aware that 1 code-specification extension with 1 or 2 codings would suit the situation better. The slicing required for that, currently leads to validator issues and I've asked Grahame for help to investigate. This may lead to another update in the profile-to-be. Since the expectation is that you have ISO xor GBA not both at the same time, you would not have 2 code-specification extensions anyway.
Job Schipper (May 14 2020 at 09:54):
should i keep following https://bits.nictiz.nl/browse/MM-1155 for these changes?
Alexander Henket (May 14 2020 at 19:08):
If I need to update the profile, then yes, that ticket is updated. For now we have a profile that works, so for the short term I'm putting my money on that one.
Job Schipper (May 15 2020 at 07:59):
@Alexander Henket Ok we'll have a try with that one. Talking about versioning, when i reference a Nictiz profile by it's URI, it does not seem to contain a version number (i.e. "http://fhir.nl/fhir/StructureDefinition/nl-core-patient"). Let's say that I have some patients that were made a while ago that reference the profile nl-core-patient, and they were made back when we had version 1.3 of that profile. Now when i load the latest nl-core-patient profile on the server, all my existing patient resources now all of a sudden point to the updated version of "nl-core-patient", and because of this they probably are not valid anymore. Do you have a suggestion on how we could best handle this? Wouldn't it make sense to add a version number to the profile URI so that we can have older resources referencing the older version, and newer resources referencing the newer version?
Job Schipper (May 15 2020 at 08:00):
I could also imagine this leading to problems when I receive a Patient resource from a 3rd party, that references "nl-core-patient", but I don't know what version of "nl-core-patient" they are using
Alexander Henket (May 15 2020 at 09:20):
There are many discussions on versions in the canonical or not. We've settled years ago for what I think still is the consensus which not to have the major version in the canonical. The second part is that all data is assumed to be valid against the same package. If you persist FHIR resources as-is, this requires you to map the persisted FHIR resource against the expected FHIR resource. This is in no way different from when you would have persisted in a SQL DB
Grahame Grieve (May 17 2020 at 20:01):
working further on this - you cannot use extensible bindings to differentiate slices
Grahame Grieve (May 17 2020 at 20:12):
@Alexander Henket that's why the validator wasn't behaving as expected. I'll have to review the code - there should be some kind of message, but once the code systems are defined and the bindings are required, then it all works as expected
Last updated: Apr 12 2022 at 19:14 UTC
