Stream: implementers
Topic: Expectations for references when posting Observation
Alexander Henket (Sep 09 2021 at 21:03):
Suppose I want to send vitals to my GP and I'm client only. What's the expectation for Observation.subject? Since I'm client only I can't let it reference my 'server'. Do I need to include my copy of the Patient resource? Do I have to prenegotiate what the resource.id of the Patient resource at my GP is?
The Observation is the focal resource and all I care about is that my Observation 'gets there'. I may additionally wish to add Observation.performer(RelatedPerson) but that's about it. Are there any IGs that deal with this? There's a couple of them listed but everything is 404 or boiler plate text.
Jens Villadsen (Sep 09 2021 at 21:06):
cant you use a logical reference to your subject?
Cooper Thompson (Sep 09 2021 at 21:27):
If your are sending the Observation in the context of a SMART on FHIR app, then the subject (patient) can be solved by the server's patient FHIR ID you'll get in the SMART launch flow. However that really only works for patient references. You end up with the problem you describe for other reference types (Encounter, Device, etc).
Rik Smithies (Sep 09 2021 at 23:15):
or you can use a transaction with a conditional query that can look up the patient id by identifier, and get the server to populate the subject automatically. See http://hl7.org/fhir/http.html#trules and conditional references
Elliot Silver (Sep 09 2021 at 23:18):
Jens Villadsen said:
cant you use a logical reference to your subject?
Agree, use Reference.identifier and send the patient MRN or similar. The server can resolve the reference when the Observation is received.
Also, agree with @Rik Smithies's approach.
Alexander Henket (Sep 10 2021 at 05:10):
In our setup, the PHR and the EHR do not share any Patient.identifier nor Patient.id. By law the PHR is not allowed to have the national patient identifier as part of its setup. The only place where they share context about who the patient is, is in the OAuth token which is not obtained through SMART on FHIR. Hence the logical reference would not work in our setup.
I somehow get the feeling that RESTful approaches fail in our circumstances and a messaging paradigm comparable to a V2 ORU_R01 suits better.
Richard Townley-O'Neill (Sep 10 2021 at 06:42):
Maybe use reference.identifier with a value that only identifies the person within the message/bundle/response. Something like 'Patient1'.
Rik Smithies (Sep 10 2021 at 07:40):
So the 2 systems both know who the patient is, but the only link is the OAuth token?
Conditional reference doesn't need to use Patient.identifier, but there would need to be some FHIR data item or combination of items that would always work. Same applies to any FHIR based approach e.g. logical reference.
Probably no useful context can be given, except for the OAuth token, which is already known (outside of FHIR).
There is no reason not to use REST though. REST servers can add extra information if they know it, from the context, just the same as a message infrastructure could. If the server wants to add a value for the subject then it can. But I suppose you are looking for some semantic to say "you know who this is so please fill in the subject"? Perhaps that can just be understood behaviour. It's not illegal behavior anyway.
Alexander Henket (Sep 10 2021 at 10:17):
What I would like to achieve functionally is to submit my vital signs in the context of a Patient resource that I can give you the resource for as I know it to be without anyexpectation whatsoever on my part that you as receiver will persist that’ll Patient resource. It's just there to - in addition to the token which is very precise - to provide you context around my Observation.
It's maybe something like: "here's my vital sign X. Please add that to my health record that you can find based on the token. If you want you may also have a look at my Patient details as I know them to be in my PHR".
Rik Smithies (Sep 10 2021 at 11:24):
"in the context of a Patient resource" - are you expecting the client to send a patient resource (sounds like it)? Are you expecting the server to have a patient resource before this? Or the server to have one after? Or the server to have only one even though multiples are sent by the client?
Rik Smithies (Sep 10 2021 at 11:34):
Maybe what you do depends on to what extent what the server record needs to actually be FHIR, with usable references, or some other patient context (i.e. a bunch of unlinked FHIR resources and an OAuth id).
John Moehrke (Sep 10 2021 at 13:07):
If I understand this correctly.. I would recommend the client doesn't populate the .subject; and the server populates it based on the OAuth token.
John Moehrke (Sep 10 2021 at 13:08):
even if the client does put something there, it seems like your policies should have the server override the subject with the patient id that the server divines from the Oauth token.
Daniel Venton (Sep 10 2021 at 13:15):
Is there any thought that in the future the user might be submitting the Observation on behalf of somebody else, say a minor or acting as a personal rep?
Cooper Thompson (Sep 10 2021 at 13:37):
In SMART on FHIR context, you should have both the user and patient as separate concepts. So the patent/minor scenario should "just work". The "patient" context param in SMART on FHIR is very specifically the patient (e.g. the minor), where the user in the OIDC token would be the parent.
Craig McClendon (Sep 10 2021 at 19:17):
One option is to model it as a Message Bundle.
The Bundle would include a Patient and Observation(s), with local IDs.
By local IDs, I mean IDs either local only to that bundle or perhaps to the source system, but that have no meaning to the target system. They are there just to maintain the referential integrity within that bundle.
The endpoint receiving the message bundle will have to understand the message type and perform patient matching when receiving to determine the target Patient id/resource, and update the references accordingly before persisting it.
Rik Smithies (Sep 10 2021 at 19:48):
That sounds a lot like the match and replace system that is built into FHIR transaction bundles already. I suppose with a message it could be more flexible, since it won't be the default server implementation (it could use the OAuth context etc.), but it would be good to at least be consistent with transactions, i.e. using fullUrl placeholders.
Craig McClendon (Sep 10 2021 at 21:46):
It does, and I suppose that is the simplest option if you do not need any special matching logic outside of what can be expressed in a single fhir patient search string, you can trust (or authorize) the client, etc. The messaging option might work if you need specialized logic or semantics, more complex matching/de-duplication, etc. But then it's not a FHIR API, it's a custom API that uses FHIR payloads.
Saad Naseem (Sep 13 2021 at 07:24):
Hi All, my question is: How much the cost of FHIR services if we use Azure health API for fhir ?
Grahame Grieve (Sep 14 2021 at 05:53):
I somehow get the feeling that RESTful approaches fail in our circumstances and a messaging paradigm comparable to a V2 ORU_R01 suits better.
@Alexander Henket that depends on perspective. The business rules have to be injected somewhere. They can be injected into a RESTful framework, but there's no way to get them for free. But that also applies to messaging - you still have to actually put them somewhere.
Alexander Henket (Sep 16 2021 at 14:58):
We had a broader team discussion here on topic. Things we came up with:
- Use pre-known context. If you have received data from the receiving party: reuse the Patient/Practitioner/RelatedPerson.id from that. For sending patient corrections we actually require the capability to query your patient summary. It is therefor likely you can know those. You then only need to send the references to things the receiving party would already have. Note that in our context, a lot of parties will not have stable Resource.ids to point to so this is not fool proof
- Use contained resources, where you populate everything you know about Patient/Practitioner/RelatedPerson. This avoids the necessity for (conditional) create. We would allow freedom on the server side to replace the contained resources with copies as they already have
- For Patient specifically there is a shared context through the OAuth token. So ... as per suggestions here, you could refer to that. We could not immediately find howto, but a method could be:
<subject>
<identifier>
<use value="temp"/>
<!-- https://datatracker.ietf.org/doc/html/rfc7519 JSON Web Tokens -->
<system value="urn:ietf:rfc:7519"/>
<value value="7WK5T79u5mIzjIXXi2oI9Fglmgivv7RAJ7izyj9tUyQ"/>
</identifier>
<display value="Alexander Henket"/>
</subject>
There's a last method we currently have in production: send POST in the Bundle for Patient but allow the server to simply ignore that and substitute with what's known from the token. That method we deemed ill-architected.
Lloyd McKenzie (Sep 16 2021 at 17:28):
Contained resources are not intended for you to minimize the number of interactions. Contained is appropriate when if you were to query based on the information you have, you couldn't possibly resolve to a single instance and therefore the information you have isn't sufficiently unique. They're not a way to toss everything you want over the wire and expect the receiver to reconcile and resolve. If you send something as a contained resource, you should expect it to be stored and propagated as a contained resource. (In some circumstances, a recipient might have enough supplemental information to resolve a contained resource and choose to do so, but there's never an expectation to do so.)
Alexander Henket (Sep 16 2021 at 20:01):
They are not meant to minimize interactions. They are meant as fallback method if other methods fail (reuse references received earlier from this server, reference to token).
If you use contained resources you could resort to either a reference to something that is a query, as written in the transaction processing rules, but I have no way of knowing what search parameters will be sufficiently unique unless I know an identifier in which case I could have just used a logical reference instead. The alternative is conditional create for which the same applies but it's worse because I don't actually care about how the receiver processes my Patient/RelatedPerson/Practitioner. With a conditional create I'm telling the server how I think he should handle my Patient resource. I only care about the Observation being persisted and connected to his set of resources.
With a contained resource I'm giving you everything you need to know about person X, and let you figure out which part(s) you want to use to find the right counter resource ... if any. And if you simply want to persist as-is that is fine too if that works for you.
We're not completely set in stone here, but this is one of final hurdles. Any hints on how reference a token outside the resource from within the resource? Is that something other contexts than ours could be interested in?
Lloyd McKenzie (Sep 16 2021 at 23:24):
Your presumption with 'contained' is that it'll be stored "as is". Don't understand your last question
Last updated: Apr 12 2022 at 19:14 UTC
