Stream: hapi
Topic: HAPI contained resource referencing parent
Rik Smithies (Aug 24 2019 at 00:45):
HAPI strips out contained resources that are not referenced by the parent.
But these may actually be valid, if the contained resource references the parent, instead of the usual opposite direction.
It filters out this contained resource, even though the target element references the parent (and still does if it uses a proper id in the reference rather than just '#')
<Observation>
<contained>
<Provenance>
<target>
<reference value="#"/>
</target>
Is there a way to structure this so HAPI accepts it? Adding a dummy id or something?
James Agnew (Aug 26 2019 at 10:39):
Is that valid for a contained resource to reference the container but with no references the other way around? My understanding has always been that it isn't...
Grahame Grieve (Aug 26 2019 at 10:41):
that was changed in R4
James Agnew (Aug 27 2019 at 01:41):
Hmm... Well, sounds like we need to remove that check or make it more nuanced then now.
@Rik Smithies as a short term workaround you could add a dummy extension from your outer resource pointing to your inner one... it's ugly i know but it would work
Kevin Mayfield (Aug 27 2019 at 07:45):
Do we have any references to the change? Wondering what the use case is ... and I've seen a number of 'standards' coming out which (unnecessarily and inconsistently) make use of contained.
Rik Smithies (Aug 27 2019 at 11:07):
My use case is to add a data item for the Observation "source system". I wanted to use Provenance but don't want to have a Provenance end point. Hence a contained Provenance in each Observation. And they point to Observation rather than the other way around.
It's a prototype and we may go to full Provenance eventually. But in the mean time I wanted to round trip the data to FHIR and check it all went in and out again, so a contained Provenance does the job for now.
Kevin Mayfield (Aug 27 2019 at 13:17):
That makes sense, probably saves a lot of calls.
The one I've just seen (below), is an example of one I think is wrong. The contained reference is likely to be static (and the contained resource is mandating other contained resources!).
Contained.PNG
Kevin Mayfield (Aug 27 2019 at 13:18):
HL7v3 in disguise?
Rik Smithies (Aug 27 2019 at 17:06):
Well if there is a known set of organizations and they are well identified and re-used, it should not be a contained resource.
A use case for a contained organization is if you have low quality data. e.g. hand entered names "St Agnes Hospital" and "Saint Agnes Hosp". You can't create a resource for every variation of the name and can't easily canonicalize the strings (and it may not even be the same hospital). So a contained resource with just the name can work.
I have considered an empty reference and putting the org name in reference.display, but I think that might be cheating.
Kevin Mayfield (Aug 28 2019 at 09:26):
Think it's sensible to put in sensible to put in display and reference.identifier where possible - in UK for organisation references this would be ODS code (and this links to HL7v2 standards in UK) e.g.
"managingOrganization": {
"reference": "Organization/self",
"identifier": {
"system": "https://fhir.nhs.uk/Id/ods-organization-code",
"value": "B81603"
}
}
Kevin Mayfield (Aug 28 2019 at 09:27):
You've then got the choice of following the reference or using the ODS server to resolve the organisation.
David Hay (Sep 01 2019 at 19:21):
@Rik Smithies - why would that be cheating? Seems a valid use of reference,display to me...
Rik Smithies (Sep 01 2019 at 23:15):
@David Hay I always assumed display was there to support the actual reference and was not intended to replace it. Is that not the case? One of my main reasons for using contained would not be needed if that use is actually legitimate.
Grahame Grieve (Sep 01 2019 at 23:17):
if there
Grahame Grieve (Sep 01 2019 at 23:18):
it's valid to have just a display, if that's all you have about the target of the reference. Obviously, it's a lot less functional than an actual reference
David Hay (Sep 02 2019 at 00:06):
I saw it kinda like an intermediate step - "this is all I have right now, as systems mature and become more FHIR enabled then a 'real' reference might become available later..."
Rik Smithies (Sep 02 2019 at 10:08):
If it's ok to use reference.display alone for a name or short description of the referenced item that seems to remove one of the uses for a contained resource. Contained can be for when the item is not "identifiable". But if you have more than one data point (so it can't all go in reference.display) then it seems a better chance it can be identified. An exception could be a forename and surname I suppose, though concatenating them wouldn't seem a big issue for such an "unidentified" person. And it's a lot simpler than contained.
Kevin Mayfield (Sep 02 2019 at 10:12):
From working on a GP Connect client (and also supplier) perspective. The references can contain most of what is needed by a client and helps prevent a chatty API.
Rik Smithies (Sep 02 2019 at 10:35):
Hi Kevin, do you mean the single string of reference.display is sufficient?
Chat is reduced by both the reference.display and contained resource route. But you can get more structure in contained. But now I am seeing less cases where that middle level of structure is necessary.
If it's a fully identified thing like an ODS reference, then this isn't so much of an issue, that would never really be contained. Reference.display is still helpful there of course. But not on it's own.
Kevin Mayfield (Sep 02 2019 at 10:47):
I think that's what I'm seeing. Reference.display is often sufficient, if not a reference or identifier reference can be followed. If following the reference creates a very chatty interface then contained can be used, if not very chatty consider local caching to avoid repeated reference lookups?
Last updated: Apr 12 2022 at 19:14 UTC
