Stream: implementers
Topic: symmetric relationships Specimen<->ProcedureRequest
Andrew Patterson (Aug 25 2017 at 12:27):
From 2.3.0 Resource references "The corresponding reverse relationship from the target to the source exists in a logical sense, but is not represented explicitly in the target resource.".. What happens when the logical reverse relationship could be represented in the target resource?
So in a specific example - if I create a new Specimen resource with a 'request' reference to an existing ProcedureRequest. Then I fetch the ProcedureRequest - should there be a link back to the Specimen now as a reference from the 'specimen' field? This seems to be unlike say the case of where there is a 'subject' relation to a patient. Obviously there is no slot pointing back to the ProcedureRequest from Patient. But what do we do when there is?
Is this something an implementation could do but wouldn't be expected? Explicitly forbidden?
Grahame Grieve (Aug 25 2017 at 15:19):
nothing is forbidden. you can always use an extension. but do you really need to do that? we avoid circular reasons where we can for obvious reaosns
Andrew Patterson (Aug 25 2017 at 23:39):
Yes, I wouldn't put in an extension to deliberately create a circular relationship. But in the case of Specimen<->ProcedureRequest the circularity already exists (unless I've misunderstood the modelling). Specimen has a reference back to the ProcedureRequest, and ProcedureRequest has a list of Specimens. I guess I'm asking to what extent the server would be expected to ensure sanity here. If I add a specimen reference into the ProcedureRequest - but the referenced Specimen points to a unrelated/different ProcedureRequest - is anything in the spec about how I should behave. Allow? Reject the added Specimen? Correct the back link?
Lloyd McKenzie (Aug 26 2017 at 03:15):
The specimen on ProcedureRequest is used when you want to say "please do this test on these existing specimens". The pointer to ProcedureRequest on Specimen is "this specimen was taken to satisfy this order". You should never have a circular situation.
Andrew Patterson (Aug 26 2017 at 04:57):
Thanks Lloyd. As the specimens exist and have been processed - before our test (our test is more computation than actual physical testing) - I think the 2nd form is what we will need to use.
Lloyd McKenzie (Aug 26 2017 at 14:12):
So ProcedureRequest points to pre-existing specimen.
Eric Haas (Aug 28 2017 at 15:50):
In Fact ProcedureRequest and Specimen request are structures so that one can point to the other depending on the workflow.
-
http://build.fhir.org/specimen-definitions.html#Specimen.request
-
http://build.fhir.org/procedurerequest-definitions.html#ProcedureRequest.specimen
We explain the different workflow in the comments. If you feel this is inadequate feel free to submit a tracker with a suggested update to the guidance.
Andrew Patterson (Aug 28 2017 at 22:55):
Thanks Eric. I think we're a bit of a weird edge case at the moment, so both can somewhat apply to our workflow. If I can come up with any language clarifications I will put in a tracker.
Last updated: Apr 12 2022 at 19:14 UTC
