Stream: IG creation
Topic: Validator can't follow references in contained resources
Jean Duteau (Jan 28 2021 at 22:59):
I have a profile on a resource that has contained resources. Those contained resources reference the containing resource and other contained resources (Organization.contained[1] = HealthcareService, Organization.contained[2] = OrganizationAffiliation, Organization.contained[3] = Organization2. OrganizationAffiliation references the containing resource and Organization2. I am using the '#' to refer to the containing resource and "#blah" to refer to other contained resources as it indicates in the specification: http://hl7.org/fhir/references.html#contained
Unfortunately, it appears that the validator can not resolve those references. I have a slice that is of type #profile and thus the validator needs to resolve that reference and it complains about it.
Unable to resolve resource '#'
NOTE: This only occurs if I set the slicing to be of type #profile. I suppose that it doesn't need to resolve the references otherwise.
Jean Duteau (Jan 28 2021 at 22:59):
unfortunately, this is raised as an error and not a warning, so I can't suppress them.
Elliot Silver (Jan 28 2021 at 23:31):
Organization.contained[3] = Organization
I assume you've simplified here, and this isn't a circular reference?
Jean Duteau (Jan 28 2021 at 23:31):
sorry, yes, it's a different organization that is referenced by the orgAffiliation (I updated my original post to reflect that)
Elliot Silver (Jan 28 2021 at 23:34):
Interesting. I wonder if the validator expects only the containing resource to reference contained resources, not contained resources to reference each other? This is on a profile... I wonder what the instance behaviour would be?
Jean Duteau (Jan 28 2021 at 23:35):
it's not actually complaining about that - it's complaining that it can't find the containing resource in HealthcareService which only references the containing resource.
Elliot Silver (Jan 28 2021 at 23:36):
right. (The second part of my comment still stands.)
Jean Duteau (Jan 28 2021 at 23:37):
true. i'm expecting that servers who support contained resources would support this way of referencing them, but I'll certainly have the team test that.
Elliot Silver (Jan 28 2021 at 23:41):
Can you simplify the example? You start off saying Org1 contains HCS, OA, Org2; OA references Org1, Org2. But then you say HCS references Org1, and that's where the error comes up. Are OA and Org2 just a distraction from the issue?
Jean Duteau (Jan 28 2021 at 23:42):
yes, i have a simpler instance that just has Org1 containing HCS which HCS referencing Org1. And that fails as well.
Lloyd McKenzie (Jan 29 2021 at 04:55):
In R4, there's an invariant that mandates that all contained resources must directly reference the container or be referenced by the container. There's no support for container references contained1 which then references contained2. This is a known issue. Unfortunately, it's not super obvious how to fix it. There's no easy way to say "contained resource must reference or be referenced by the container either directly or through some recursive reference path via other contained resources" using FHIRPath (let alone XPath). @Grahame Grieve @Bryn Rhodes thoughts on how we can tackle this in R5?
In R4, only solution is have a useless extension that includes a reference to the parent (or from parent to non-directly linked children)
Jean Duteau (Jan 29 2021 at 05:41):
Okay, that's going to put a crimp in my profiling plans. I still don't think that is my current issue as I have a Organization resource that has a contained HealthcareService that references the parent and I'm still getting the error in the QA of "unable to reference #".
Jean Duteau (Jan 29 2021 at 05:44):
because I'm using OrganizationAffilation to just show a link between the parent Organization and the contained Organization, if I'm going to have to define an extension to meet the constraint, I might as well drop the use of the OrganizationAffiliation.
ryan moehrke (Jan 29 2021 at 16:39):
unless i'm parsing the fhirpath wrong, as long as somewhere in the resource, other contained resources too, there is the correct #id reference (it doesn't seem to even care if it's self-referential, at least in the invariant) or the contained resource itself has a '#' reference to the containing resource then there isn't a problem.
Lloyd, where in that invariant do you see that the #id reference search doesn't include other contained resources?
for reference I'm looking at dom-3 https://www.hl7.org/fhir/domainresource.html#invs
Jean Duteau (Jan 29 2021 at 16:43):
I was going to come back this morning to report that after I made the change above - using an extension and deleting the OrganizationAffiliation, I suddenly get an error on the constraint Lloyd mentioned. I didn't get that constraint failure before. So I went from the validator not being able to follow # references to it not being able to do that and the constraint firing. :)
If anyone wants to see the errors, the latest fhir-spl guide has them: http://build.fhir.org/ig/HL7/fhir-spl/branches/main/qa.html
ryan moehrke (Jan 29 2021 at 16:51):
I mean the obvious question is why do you need contained resources (especially this many) but it should work from everything I'm seeing..
Jean Duteau (Jan 29 2021 at 16:54):
we don't actually have that many contained resources. We have a parent Organization that identifies two optional Organizations who perform services for it and a set of HealthcareServices that define its services. We determined that none of the contained resources actually have a lifetime/identity of their own.
Grahame Grieve (Feb 01 2021 at 21:04):
There's no support for container references contained1 which then references contained2
I don't think that this is true
Jean Duteau (Feb 01 2021 at 21:05):
Grahame Grieve said:
There's no support for container references contained1 which then references contained2
I don't think that this is true
Yeah, I think we determined that since my guide doesn't complain about that constraint.
Lloyd McKenzie (Feb 02 2021 at 17:11):
The current invariant allows A to contain B and C where B and C point to each other, but neither have a reference to or from A - which does not meet our objective.
Jean Duteau (Feb 02 2021 at 21:58):
to get back to my original concern/problem - it appears that the validator can't resolve the references between contained resources. I made a simple instance where the contained resource had a reference back to the container via <reference value="#"/> and I got the error "Unable to resolve resource '#'". So I don't think that the validator in the IG publisher supports those references?
Grahame Grieve (Feb 02 2021 at 22:08):
how do I reproduce this? I think it should work
Jean Duteau (Feb 02 2021 at 22:08):
i checked in my guide (fhir-spl) which has that error.
Jean Duteau (Feb 02 2021 at 22:08):
If anyone wants to see the errors, the latest fhir-spl guide has them: http://build.fhir.org/ig/HL7/fhir-spl/branches/main/qa.html
Jean Duteau (Feb 02 2021 at 22:09):
btw, i'll be glad to be told that the validator is fine and I'm doing something wrong
Grahame Grieve (Feb 04 2021 at 01:59):
ok fixed next release. It turned out that # was supported, but there was a bug in the implementation of conformsTo()
Last updated: Apr 12 2022 at 19:14 UTC
