Stream: implementers
Topic: Usage of duplicate fields across resources
Tim Berezny (Oct 01 2019 at 13:27):
We are profiling a referral/ServiceRequest process, and are trying to figure out how to deal with redundant links to resources.
In the referral process, we send a ServiceRequest, and then there is a bunch of other data that can come with it (or be added later) that is always related to the ServiceRequest and POINTS to the serviceRequest. e.g.,
- Appointment.basedOn --> ServiceRequest
- Communication.basedOn --> ServiceRequest
- QuestionnaireResponse.basedOn --> ServiceRequest
Each of these resources also references the Patient who is the subject of the ServiceRequest, but the ServiceRequest itself identifies the patient ... so it becomes redundant for appointment/communication/questionnaireResponse to reference the patient when we can find out who the patient is via the ServiceRequest.
My Question is: should we reference the Patient resource from Appointment/Communication/QuestionnaireResponse when it has to always be the same Patient that is referenced in the linked ServiceRequest? My first inclination is NO, because it could cause confusion if ever the referenced patient is different than in the ServiceRequest (which they never should be).
Tim Berezny (Oct 01 2019 at 13:52):
Note: We are using a messaging paradigm for this specification.
Lloyd McKenzie (Oct 01 2019 at 14:08):
Yes. There's no context inheritance with FHIR. If something is for a patient, that must be explicitly declared, it can't be inferred. The data that is received in a message might subsequently be exposed with REST and the relationships will all need to exist. As well, the logic for propagating context is inevitably complex and scenario-specific, which significantly increases implementer cost. The references don't take up much extra bandwidth and the compression that happens during transmission makes them take up considerably less.
Tim Berezny (Oct 01 2019 at 15:02):
Is it fair to say in an implementation Guide that the Patient in ServiceRequest and Appointment must match (when in the same message), or else the message will be rejected?
John Wills (Oct 01 2019 at 15:18):
For this scenario would these not be considered Contained Resources? http://hl7.org/fhir/references.html#contained. i.e. contained in the message bundle with ServiceRequest? In which case an external RESTful reference may never exist.
Lloyd McKenzie (Oct 01 2019 at 15:24):
Contained means that the resource is contained within one of the resources. Contained resources can't be referenced by any other resources in the Bundle. There's no requirement that the resources be exposed RESTfully in the source system. The target system might choose to expose them RESTfully, which means the RESTful principles still need to be adhereed to.
Lloyd McKenzie (Oct 01 2019 at 15:25):
It's absolutely possible to set business rules about what references must be the same in the context of a particular message event. (GraphDefinition tries to provide a way to do this, though it hasn't been terribly well exercised in the context of MessageDefinition (or anywhere, really)
Grahame Grieve (Oct 01 2019 at 20:41):
Contained resources can't be referenced by any other resources in the Bundle
That's not true. But it's certainly generally true that you should only ever use contained resources when you can't identify the content (e.g. you have just a name for a practitioner)
Last updated: Apr 12 2022 at 19:14 UTC
