Stream: patient empowerment
Topic: Expectations on (bundle) references
Niek van Galen (Sep 10 2021 at 11:59):
I am looking at the latest version of the Patient Corrections IG (https://build.fhir.org/ig/HL7/fhir-patient-correction/examples.html) to use for a Dutch use case.
We want to use the Communication only scenario, and also use a reference to a Patient (as sender) and Practitioner (as recepient). However, the IG does not state anything about resolving those references, for instance in a transaction bundle. My expectation is that when a client sends the Communication resource to a server, the client includes the Patient and Practitioner resource in the bundle. Because we can not expect the client to expose an endpoint where the server can resolve the references.
I am wondering what your thoughts on this subject are.
Lloyd McKenzie (Sep 10 2021 at 14:33):
In general, the expectation is you point to specific Patient and Practitioner instances that already exist on a server somewhere. If you use a transaction bundle with all 3, then you're asking to create the Patient and Practitioner as well as the Communication - and that typically isn't what you want to do.
John Moehrke (Sep 10 2021 at 14:54):
The work is very early, so has not addressed everything. As Lloyd has mentioned a simplifying assumption, that we have made so as to focus on the meat of the problem, is these kind of details.
In an early version I had Patient and Practitioner nailed down; but it was felt that using two profiles for the two different directions could be made more general into one communication where it was left to the reader to understand the to/from details.
Virginia Lorenzi (Sep 12 2021 at 20:40):
Communication.subject is always the Patient. Did you look at the definition of sender and recipient in the latest Communication profile? https://build.fhir.org/ig/HL7/fhir-patient-correction/StructureDefinition-patient-correction-communication.html. FYI we have veered away from Communication alone for now and are focusing on Communication spawns Task, but the guide still allows for a Task not to be spawned.
Virginia Lorenzi (Sep 12 2021 at 20:44):
What I would expect in the bundle for a Communication resource representing a request for correction would be any resources referred to from Communication.payload. If there are referenced resources from payload that would be expected to be included in a bundle, how do we describe that in an IG - are there examples of that in another IG I can look at?
Lloyd McKenzie (Sep 12 2021 at 20:50):
Typically you'd either just have the Reference and the recipient would go query for them or you'd wrap both in a transaction and ask for both to be created. A third option would be to base64 encode the payload resource and send it as an attachment.
Niek van Galen (Sep 13 2021 at 06:59):
Lloyd McKenzie said:
In general, the expectation is you point to specific Patient and Practitioner instances that already exist on a server somewhere. If you use a transaction bundle with all 3, then you're asking to create the Patient and Practitioner as well as the Communication - and that typically isn't what you want to do.
In this particular use case we do not know if there is a Patient and/or Practitioner resource present on the server, but we also do not want to enforce using the ones we send in the bundle. Would there be a way to send both resources along with communication but make it optional to create them?
Ardon Toonstra (Sep 13 2021 at 07:23):
In general, the expectation is you point to specific Patient and Practitioner instances that already exist on a server somewhere.
Would it be common to first perform queries to find matching resources on the server and use those ids in the references for the resources you want to create?
Virginia Lorenzi (Sep 13 2021 at 15:02):
Since you are requesting corrections to a record you already have, you should already have the id of the patient resource and the organization or provider. The provider is not required necessarily. At my hospital, I expect that who will work on the correction will be refined there.
Virginia Lorenzi (Sep 13 2021 at 15:04):
So you have a correction request for a patient that you are sending to a provider, but do not already have the patient resource? Interesting. Explain.
John Moehrke (Sep 13 2021 at 15:07):
I would expect most of the time you (the patient + their app) would know the patient id and the id of the FHIR resource that needs correcting (or the CDA document that needs correcting). This assumption is based on the fact the provider is providing a communication method for registering correction requests... presumably at that point the patient has already engaged with taht provider using FHIR.
John Moehrke (Sep 13 2021 at 15:08):
the alternative is a patient -> provider relationship that allows FHIR Communications, but does not have any other FHIR api? That seems unusual... One example would be where provider offers a web-browser user experience, but in that case that app (the web browser backend) is internal to the provider.
Lloyd McKenzie (Sep 13 2021 at 15:39):
Looking up/figuring out what the patient id is pretty much always a pre-requisite to doing anything. It's possible to use a messaging approach and say "here's a bunch of stuff, you figure it out - good luck", but that's generally a last resort option.
Virginia Lorenzi (Sep 14 2021 at 04:18):
Coincidentally we discussed bundles at the track kickoff today and I believe decided we should try an operation on Communication bundled with resources referenced by Communication.payload
David Hay (Sep 14 2021 at 04:37):
And pretty much implemented in the the server I'm building - will discuss tomorrow at the catch up. Interestingly, it actually made it much easier to include other resources - eg referenced from the communication.payload, or the Patient resource itself if the id on the server is not known. Be interesting to see what others make of it...
Niek van Galen (Sep 14 2021 at 09:04):
Thank you all for your valuable comments on this topic. Indeed it would make sense that the PHR already "knows" the patient (and possibly) other resource id's, but in the MedMij / Dutch context this is not always the case or possible. We are however going to strongly advice on this, and keep the messaging option @Lloyd McKenzie posted as a last resort.
I am also looking forward to seeing option on Communication bundled with resources that @Virginia Lorenzi mentioned.
Last updated: Apr 12 2022 at 19:14 UTC
