FHIR Chat · Bundle Transaction References · implementers

Stream: implementers

Topic: Bundle Transaction References

Jose Montoya (Dec 04 2016 at 22:45):

Let's say I want to submit several DiagnosticRequests grouped by RequisitionId.

I build a Transaction Bundle where I have all the DiagReqs all with the same RequisitionId and each entry with Request = POST. Everything in order so far.

Now according to http://build.fhir.org/request.html#requisitionid "common information (patient/practitioner/authoredOn) can be seen by examining any of the Request instances that share that requisitionId" so I put a contained patient in every DiagReq.

Could I add a Patient entry on the bundle without specifying that it be part of the transaction, but only as a common resource to other entries in the bundle?

Eric Haas (Dec 04 2016 at 22:57):

Assume you mean a pateint resource... yes

Jose Montoya (Dec 04 2016 at 23:07):

Yes, a Patient resource. Great, thanks.

Jose Montoya (Dec 04 2016 at 23:07):

Now, when I add that patient to the bundle, can I still keep the type as Transaction or does it change to Collection? I ask because http://build.fhir.org/bundle.html#transaction says that if I don't include a Request for an entry "server must infer whether this is a create or an update"

Jose Montoya (Dec 04 2016 at 23:08):

And I don't want that Patient to be created or updated, just serves the purpose of a reference to multiple other entries.

Grahame Grieve (Dec 04 2016 at 23:15):

you need to read about conditional creates.

Jose Montoya (Dec 04 2016 at 23:45):

I think I understand how conditional actions work, the thing is that in this scenario for example I'm putting a Patient entry to serve as a reference for all other entries because I don't have a Patient resource. I guess I could return something like "404 Not Found - resource type not supported, or not a FHIR end-point" according to http://build.fhir.org/http.html#create but I'd rather not have to deal with that if possible.

Grahame Grieve (Dec 04 2016 at 23:58):

I'm not sure what you mean by patient entry vs patient resource in that sentence

Jose Montoya (Dec 05 2016 at 00:02):

The bundle has 2 diagnosticRequests entries, both of those requests have the same patient subject. Since I don't support a patient/ resource I'm putting the entire patient inside a container on each diagReq.

Jose Montoya (Dec 05 2016 at 00:02):

What I want to do is add another entry to the bundle that the diagRequests reference using http://build.fhir.org/bundle.html#references

Jose Montoya (Dec 05 2016 at 00:03):

My question is that I want the bundle to be a transaction that only encompasses the diagRequests.

Grahame Grieve (Dec 05 2016 at 00:04):

if you're using contained patient resources, then every request will have to contain the same patient resource

Jose Montoya (Dec 05 2016 at 00:09):

Ok, that contradicts what @Eric Haas said earlier.

http://build.fhir.org/bundle.html#references allows me to reference a Patient bundle entry from within DiagReqs entries. What makes it a little confusing is that I only want the DiagReqs to be part of the transaction. The Patient bundle entry is just a convenience so that I don't have to repeat the same patient within every Req.

Grahame Grieve (Dec 05 2016 at 00:10):

I don't think it was clear that you were talking about contained resources when Eric answered

Jose Montoya (Dec 05 2016 at 00:12):

Oh

Grahame Grieve (Dec 05 2016 at 00:13):

I don't quite understand yet.
- if you have contained patient resources, then each resource has to have it's own contained patient resource
- if you know the patient, then you can just put the patient by reference in each request, and there's no need to include the patient resource in the transaction at all
- if the pateint might not exist, then you have to haev it in the transaction

Jose Montoya (Dec 05 2016 at 00:19):

So we don't keep track of patients. Patient is only valid within the context of the DiagReq that references it.

So I already modeled a bundle that has multiple Reqs (associated by same RequisitionId) that each contain the same patient resource. What I was looking for is a way to avoid repeating that information in every req. Because of the way requests are grouped I might end up receiving a bundle of 10 requests all containing the same repeated info (Patient, Coverage for those DiagReqs)

Jose Montoya (Dec 05 2016 at 00:20):

I thought adding an extra Patient bundle entry might solve this for us.

Grahame Grieve (Dec 05 2016 at 00:23):

no, there's no way to resolve this if you're using contained patient resources. Whenever a system processes any of the DR resources, it will have to find the patient. A contained resource is saying, 'there's no way to do identify the patient such that you can look somewhere else'

Jose Montoya (Dec 05 2016 at 00:23):

Size of each bundle could get unnecessarily big

Grahame Grieve (Dec 05 2016 at 00:23):

if you're actually able to identify the patient, but just avoiding doing so to save work, what you are discovering is that you can only move complexity around, you can't make it go away

Jose Montoya (Dec 05 2016 at 00:29):

I cannot identify the patient outside of those requests, but I could identify it within the bundle then that would save me space and some complexity. Even if end up not persisting the Patient independently.

Jose Montoya (Dec 05 2016 at 00:30):

I looked at http://build.fhir.org/requestgroup.html but it doesn't seem like it would help.

Grahame Grieve (Dec 05 2016 at 00:31):

you can't, and that's deliberate. You could save your self complexity, but you're just handing it on a magnified format to downstream systems.

Grahame Grieve (Dec 05 2016 at 00:32):

if you want to use contained patients, you'll have to repeat it in each separatable bit

Jose Montoya (Dec 05 2016 at 00:36):

Understood. I appreciate your help. I'll present an example to our client, but we'll probably just come up with our own model and not use FHIR for this use case. I think the root of this is having to separate Requests.

Jose Montoya (Dec 05 2016 at 00:46):

bundleRef.json containedRef.json

Jose Montoya (Dec 05 2016 at 00:46):

Those are the 2 different approaches, and so to confirm only containedRef.json is valid?

Grahame Grieve (Dec 05 2016 at 00:55):

bundleRef.json looks valid to me. But you've said that you don't want to create or reference a patient. I don't understand what you really want with the patient resource. Is there definitive resource that describes the patient?

Grahame Grieve (Dec 05 2016 at 00:55):

you look like you have enough identification to properly identify the patient resource

Jose Montoya (Dec 05 2016 at 01:18):

A practitioner submits several orders to our system, the orders form asks for the patient info. So at that point all we have is N number of orders an the info of the patient, not a link to their system patient resource.

Jose Montoya (Dec 05 2016 at 01:20):

To translate to fhir dstu 2 we would make 1 diagOrder and contain the patient within. Add all the separate orders in the item array and we don't have to repeat anything.

Jose Montoya (Dec 05 2016 at 01:20):

For dstu 3 there doesn't seem a way to not repeat some things because of the need to separate diagReqs

John Moehrke (Dec 05 2016 at 13:31):

Are you meaning "Contained", or simply "within the Bundle"? It seems the conversation is speaking past eachother. "Contained" is a specific word. You are speaking of an environment without a coordinaed Patient Registry; yet everyone seems to be able to describe (create a Patient object) the patients in a close-enough way. Such that a recipient can look at that, search their local Patient registry, and 'fixup' the content of the Bundle. Right?

Jose Montoya (Dec 05 2016 at 14:42):

We don't have a patient registry. The only information we have about patient is persisted as part of the diag order.

Jose Montoya (Dec 05 2016 at 14:43):

Let's put those approaches behind for a sec.

Jose Montoya (Dec 05 2016 at 14:45):

I have to support an use case where someone sends me N amount of diag orders and the patient info. N orders, 1 patient info.

Jose Montoya (Dec 05 2016 at 14:45):

How would I go about it?

John Moehrke (Dec 05 2016 at 14:58):

using conditional create - in the Bundle is the Patient and Order. The Order points at the Patient. The recipient 'conditionally' discovers that the Patient is already known, so it just fixes up the references in the Order and doesn't create a new Patient, but does create a new Order. If it is a patient not found, it will create a patient based on the Patient in the Bundle. This is NOT using the FHIR contained concept, this is conditional-create. http://build.fhir.org/http.html#cond-update

John Moehrke (Dec 05 2016 at 15:02):

wrong link.. http://build.fhir.org/http.html#ccreate

John Moehrke (Dec 05 2016 at 15:02):

I think this should work for you... right? I think this is a proper use of this...

Jose Montoya (Dec 05 2016 at 15:08):

OK yes, this would definitely work for us. Now, the catch is that we don't have a Patient/ resource.

Jose Montoya (Dec 05 2016 at 15:09):

Main want for putting the Patient in the bundle is so that it's not repeated in each request in the bundle, making the payload over the wire unnecessarily big.

Jose Montoya (Dec 05 2016 at 15:12):

Could I put it in the bundle even if at my end I don't do anything with it other than to persist it within the order?

Jose Montoya (Dec 05 2016 at 15:12):

Man... this would be simple if Requests hadn't been split.

John Moehrke (Dec 05 2016 at 15:17):

You are the sending side? As I indicated, you put what you know as the patient into the Bundle with the Order... Or are you the receiving side? For which you need to have some kind of patient registry, even if it is not a FHIR based registry... right? I don't understand the difficulty. It is certainly going to need to go in each Bundle... The only solution there, is as Grahame indicated, there needs to be a patient registry (or set of them) that can hold a persistent resource that everyone involved can reference and use.

Jose Montoya (Dec 05 2016 at 15:18):

We are the receiving side, and we don't a have a patient registry.

Jose Montoya (Dec 05 2016 at 15:19):

We only receives orders from practitioners, patient info doesn't matter outside the set of orders received.

John Moehrke (Dec 05 2016 at 15:19):

Okay.. so then why do you care to have the sender tell you who the patient is? I presume there is some reason to know who the patient is for each Order.

Kevan Riley (Dec 05 2016 at 15:20):

Why can you not store the pat information you have as a Pat Resource, and link to it (using the conditional create to creat as needed)? This would be for the scop of your Diag Reports and not an authoritative source for pat information outside of that scope.

Jose Montoya (Dec 05 2016 at 15:21):

For billing and shipping purposes. The practitioner orders 3 tests to be performed on patient x (so they send us the patient info) we need to send some sample collection devices to the patient address then run the tests and report to the practitioner. After those actions I no longer care for that patient or its info.

John Moehrke (Dec 05 2016 at 15:21):

Do you eventually pass the order on to others? As an intermediary, you would have some responsibility for some persistence... even if you used the same condiditional-create trick... internal to your system just keeping the Order and Patent together. If you are the end of the communications, then I would understand why Contained is interesting as it would work for you. The question comes if you are not the end of the Order communication

Jose Montoya (Dec 05 2016 at 15:22):

If that person ended up going to another Dr and they ordered some tests for us we'd repeat the entire process and that's the expectation

Jose Montoya (Dec 05 2016 at 15:22):

Yes, we are the ones that perform the N amount of orders.

John Moehrke (Dec 05 2016 at 15:23):

okay, so you 'forget' the Patient in your registry after closing the loop... that is your choice too... nothing demands you remember for infinity.

Jose Montoya (Dec 05 2016 at 15:23):

Right ok. So I could bring in the Patient as part of the bundle, the sender thinks that I might be persisting it as its own resource but I'm really not. And that would be ok.

Jose Montoya (Dec 05 2016 at 15:24):

Is that what you're proposing?

John Moehrke (Dec 05 2016 at 15:24):

it is common for servers to do purge operations occationally... your SOP simply has a very short purge cycle.

Jose Montoya (Dec 05 2016 at 15:24):

Gotcha

John Moehrke (Dec 05 2016 at 15:25):

you are sending the Order back to the originator, right? So they would like your response to reference the patient THEY declared... right? So really your Patient Registry is just a shadow of all your clients; not really a Patient Registry. This was not clear originally.

John Moehrke (Dec 05 2016 at 15:29):

perspective is important. I originally understood you to be describing your situation as the sender of the message, not the recipient. I understood that the sender didn't have a patient registry, but it is you as the recipient that doesn't want to have a patient registry. Is it true that your senders do have their own patient registries?

Jose Montoya (Dec 05 2016 at 15:37):

Well... First, thanks for your attention and help on this use case.

The practitioner sends me the tests they want to run and the patient info, so that I know who to send the collection devices and whom I might charge. What I care for internally is an order that has many tests that they want to run, the prac that ordered them, and the patient the tests are for. When the loop is closed on my end, the Report I send will reference the patient on their system because they do have that registry and they did send the ID with their original payload.

I can't just use a reference to their registry for our operations because it's not a publicly available system, whenever I have to ship something that info needs to be availabe. On DSTU2 DiagnosticOrder was pretty much what we want, an order with line items inside it. In that case we'd ask the practitioner to send the Patient contained within that order and that Order would be self sufficient and have all the info we need. We'd persist it like that. With the new version we have separate DiagnosticRequests (Line items) that are grouped together some other way. Here is where things become difficult.

Jose Montoya (Dec 05 2016 at 15:41):

I'm looking at http://build.fhir.org/requestgroup.html but it seems incomplete... Maybe I'm mis-reading something

Bryn Rhodes (Dec 05 2016 at 16:36):

A RequestGroup would allow you to put multiple DiagnosticRequests together, but request group is intended for cases where there may be optionality or relationships between the requests that are important.

Bryn Rhodes (Dec 05 2016 at 16:37):

It seems incomplete because it is in the middle of reconciliation. Though all substantive changes have been applied, there are still documentation changes that need to be made.

Jose Montoya (Dec 05 2016 at 16:42):

Yeah OK. From what I read it did not seem aligned with my use case. I think @John Moehrke helped distill the core issue, but I'm still not 100% on how to tackle it...

Jose Montoya (Dec 05 2016 at 16:46):

I'm thinkin Graham's statement that I have to contain the shared information in each Request might be the only way to go. Which might not be acceptable unfortunately.

John Moehrke (Dec 05 2016 at 17:24):

I think Grahame was speaking of "Contained". THat is where you put the content of Patient inside Order. With "Contained" neither you nor the sender can EVER remove the Patient information, even if you or they have a real Patient registry. The "Contained" Patient must stay inside the Order. This presents real problems for a system that has both Patient and Order as RESTful implementations.

Jose Montoya (Dec 05 2016 at 17:28):

So what do you recommend? We don't have Patient and Order.

John Moehrke (Dec 05 2016 at 17:32):

I am trying to get clear that there are two totally different things: "Contained" is a copy of Patient inside Order, and can't be disconnected. "In the Bundle" with reference from Order to Patient; is more flexible. My recommendation is "In the Bundle", as I pointed out before. It is just not the same thing as "Contained".

John Moehrke (Dec 05 2016 at 17:33):

Both are very valuable concepts... I have used both in the Profiling work I have done.

Jose Montoya (Dec 05 2016 at 18:02):

I understand the differe, and I agree, "In the bundle" is what I'd prefer. But doesn't that force us to create a /Patient/ resource? Even if short-lived.

Grahame Grieve (Dec 05 2016 at 19:49):

I read this thread, and I don't understand your rigid statement that you don't have a Paitent resource. I was product lead for an application that did exactly what your doing in my last job before FHIR, and if I tried to implement all that functionality without a table of patients, my product would be a mess, and I would have the same problems you're having as well. So I assume that you do have a patient record, to link tests by patient.

Grahame Grieve (Dec 05 2016 at 19:50):

in which case, why not have a patient end point? Your insistence that you don't have proper patient support is creating problems because you don't have proper support for patient

Jose Montoya (Dec 05 2016 at 20:12):

We can consider implementing one, and I'll bring it up. But it seems to me that we'd be doing so just for the sake of FHIR. FHIR DSTU3 to be specific.

Jose Montoya (Dec 05 2016 at 20:15):

Our FHIRless model would be a order with several tests, the patient name and address, and that's it.

Grahame Grieve (Dec 05 2016 at 21:04):

but you have a patient table, no?

Jose Montoya (Dec 05 2016 at 23:34):

Actually we don't. Just remembered something from our overall design.

Jose Montoya (Dec 05 2016 at 23:36):

What we're building is an API front for an existing back end system that handles these orders. We're building this API to be consumed by other services and figured we will use this one to start adoptin FHIR.

Grahame Grieve (Dec 05 2016 at 23:37):

@Lloyd McKenzie this is where the request group thing doesn't work so well

Jose Montoya (Dec 05 2016 at 23:37):

So the API that we're building in theory should take <whatever FHIR model we decide> and translate it into the backend system model

Grahame Grieve (Dec 05 2016 at 23:37):

the only way to make this work neatly is to make the API work the way your data model works:
- a single grouping request
- each item is a contained resource
- there's a single contained patient that all the contained resources reference

Jose Montoya (Dec 05 2016 at 23:38):

Which is something like what I've stated before: order {practitionerRequester, testsToBePerformed, patientToSendSampleContainersTo}

Jose Montoya (Dec 05 2016 at 23:38):

Yes!

Jose Montoya (Dec 05 2016 at 23:38):

Exactly what we thought we had with DiagnosticOrder from DSTU 2

Grahame Grieve (Dec 05 2016 at 23:39):

well, there's a redirection point been introduced, so it's a little more verbose. I think

Jose Montoya (Dec 05 2016 at 23:39):

How do you imagine we could do this with individual DiagRequests

Jose Montoya (Dec 05 2016 at 23:39):

?

Grahame Grieve (Dec 05 2016 at 23:42):

RequestGroup
   contained
     patient details * 1
     DiagnosticRequest * n for each item
        status
        intent
        code
        subject - reference to contained patient
  identifier - id for request
  subject - reference to contained patient

Jose Montoya (Dec 05 2016 at 23:42):

It seems to me that we could still do something like expect bundles with: 1 patient, 1 practitioner, N diagRequests all referencing the previous. Our API would aggregate all of this into what the backend takes and call it a day. No?

Jose Montoya (Dec 05 2016 at 23:43):

Oh I see...

Jose Montoya (Dec 05 2016 at 23:44):

So you suggest we put the individual diagReqs contained within the group. I thought that's what the "action" element was for, and it just seemed off...

Grahame Grieve (Dec 05 2016 at 23:46):

which action element?

Jose Montoya (Dec 05 2016 at 23:46):

http://build.fhir.org/requestgroup-definitions.html#RequestGroup.action

Bryn Rhodes (Dec 05 2016 at 23:46):

In the RequestGroup, you'd have to do that, otherwise your resource wouldn't reference all the contained resources.

Jose Montoya (Dec 05 2016 at 23:47):

@Bryn Rhodes I'm not sure I follow

Grahame Grieve (Dec 05 2016 at 23:47):

yes, you'd have to reference each of the contained diagnosticRequest resources in RequestGroup.action.resource

Grahame Grieve (Dec 05 2016 at 23:48):

@Bryn Rhodes should requestGroup be in workflow module?

Bryn Rhodes (Dec 05 2016 at 23:49):

There are several comments related to that question. Feedback from CDS was that it's hard to talk about it without all the context from either direction, so that regardless of what module it's in, you'd need explanatory and cross-referencing text in both.

Jose Montoya (Dec 05 2016 at 23:49):

Hehe ok so requestGroup.action.resource -> requestGroup.contained.[n]diagRequest
and requestGroup.contained.[n]diagRequest.subject -> requestGroup.contained.patient

Grahame Grieve (Dec 05 2016 at 23:49):

yes

Jose Montoya (Dec 05 2016 at 23:49):

Think I got it.

Lloyd McKenzie (Dec 05 2016 at 23:50):

RequestGroup is intended for grouping a bunch of pieces together that are interdependent - and it becomes the only request that has a status. To just group things together and say "these are part of the same lab order", you'd use requisition id or Task.

Jose Montoya (Dec 05 2016 at 23:51):

Personally what's your take on using this approach? RequestGroup seems somewhat subject to change in the near future.

Jose Montoya (Dec 05 2016 at 23:52):

Well... Already kinda went down the path of using RequisitionId but then it seems I kinda HAVE to have a /Patient/ resource for it to work neatly.

Grahame Grieve (Dec 05 2016 at 23:53):

I would recommend to use a grouping id, not RequestGroup, but the lack of a coherent patient infrastructure pushes you away from that, since you link patient to the requsest group, not the request items. The consequence of this is that maintaining the links at the item level is very verbose

Bryn Rhodes (Dec 05 2016 at 23:55):

Just commenting on this: "RequestGroup seems somewhat subject to change in the near future." Our intent is to keep these structures stable for at least the coming year, as described in the clinical reasoning module roadmap.

Jose Montoya (Dec 05 2016 at 23:57):

What if accept something like what I shared earlier: https://chat.fhir.org/user_uploads/10155/J8hXTVPokVQrKX9x8JmJ4Ifm/bundleRef.json and I just aggregate it all into what our backend accepts. I guess what's wrong about it is that I'm giving the calling service the impression that I'm actually creating an identifiable patient in my system, right?

Jose Montoya (Dec 05 2016 at 23:57):

@Bryn Rhodes understood

Neil Grooby (Dec 06 2016 at 00:39):

We have a very similar use case to @Jose Montoya and used Task as a container resource for this. We don't have the interdependences.

Jose Montoya (Dec 06 2016 at 03:05):

@Neil Grooby so you had a /task/ resource where other systems posted a completely composed task?

Jose Montoya (Dec 06 2016 at 03:07):

@Grahame Grieve don't know if you saw my msg earlier. What are the cons or impeding reasons not to do something like https://chat.fhir.org/user_uploads/10155/J8hXTVPokVQrKX9x8JmJ4Ifm/bundleRef.json and aggregate it all into our backend system model?

Paul Knapp (Dec 06 2016 at 09:46):

Perhaps as a Collection rather than a Transaction since the action is implicit in the endpoint? You aren't asking the receive to CRUD but to 'here - have this'.

Lloyd McKenzie (Dec 06 2016 at 14:20):

It depends what you expect to be able to query later

Jose Montoya (Dec 06 2016 at 14:38):

Yes ok! I think this was part of my original post on this stream. If I switch to a collection including the patient doesn't require that I persist it.

Jose Montoya (Dec 06 2016 at 14:38):

?

Jose Montoya (Dec 06 2016 at 14:39):

Yeah so basically I'd like to receive a few things but I'll decide what I persist and what I don't.

Jose Montoya (Dec 06 2016 at 14:40):

We're not expected to be queried for patients.

Jose Montoya (Dec 06 2016 at 14:43):

Or ideally in a transaction a way to say hey Post these things but these others not... Or even if I include the patient as a Post but end up not persisting it independently.

Lloyd McKenzie (Dec 06 2016 at 15:55):

If you're expected to be queried for DiagnosticRequests, then receiving a "Collection" Bundle would not result in DiagnosticRequests being independently available for query. Do note that I think it's legitimate for you to support querying against DiagnosticRequest and supporting _include on DiagnosticRequest.subject, but not supporting direct query on the Patient endpoint

Jose Montoya (Dec 06 2016 at 15:57):

Yes, we would like the approach to support querying requests.

Jose Montoya (Dec 06 2016 at 16:02):

So I guess at the end of the day my options are 2:
1- Implement /Patient/ to first create the patient and reference them from the DiagRequests.
2- Contain the patient in every DiagRequest.

Grahame Grieve (Dec 06 2016 at 19:32):

you do have the 3rd option of representing the patient as an identified resource, and then unidentifying it when processing. But as Paul said, that's not really RESTful CRUD. So for best alignment, I'd make it a message, and add a MessageHeader with your own event type. Then it would be crystal clear...

Jose Montoya (Dec 06 2016 at 21:15):

I will now look at Messages. As it stands, is this accurate to our options?

Jose Montoya (Dec 06 2016 at 21:15):

1- /Patient/: We receive a transaction bundle with 1x Patient, N diagRequests. We persist the patient and diagRequests reference that independent patient.

2- "Contained": We receive a transaction bundle with N diagRequests each containing the same patient.

3- Collection: We receive a collection bundle with 1x Patient, N diagRequests. The calling system can not infer what we're doing with the resources. We decide that we're persisting in our own model and not follow CRUD.

4- Message: To be researched.

Neil Grooby (Dec 06 2016 at 22:17):

@Jose Montoya - yes, we have other systems (3rd parties) who need us to perform services (might be to get a file copy from a practitioner, blood tests etc). We were originally looking at Order but after asking here, it was identified that Order was being depreciated and that Task would be appropriate.

Paul Knapp (Dec 08 2016 at 10:08):

@Jose Montoya Message would be: We receive a message bundle with 1x Messageheader, 1x Patient, N diagRequests.

The 'tricky bit' is that you have N diagRequests. What is your intended business behaviour if one of those requests in invalid - reject the one or reject them all? If the former then you should have made this a batch bundle containing multiple single-instance messages or standalone resources, if the latter then a message bundle where MessageHeader.data points to multiple resources (Nx diagRequest) can work if you ignore the langauge about 'focal resources' and each diagRequest would refer to the 1x Patient which would appear as a peer to MessageHeader in the bundle.

Last updated: Apr 12 2022 at 19:14 UTC