Stream: implementers
Topic: Cascaded Resource
Medi Harsini (Aug 06 2020 at 01:17):
Assuming an "Appointment" resource is sent from SystemA to SystemB but SystemB has to cascade it to SystemC (for some business related reasons):
A) Where does SystemB stores the .id generated by SystemC in the Appointment resource. Naturally the SystemB has a .ID field on the appointment once it received the resource from systemA and stored in the backend repository but what about SystemC . ID?
B) If systemC sends the confirmation (booked status) of the appointment, back to SystemB, then SystemB has to forward it back to SystemA as the true audience of this. In which part of the resource, SystemB knows that the transaction was initiated from SystemA to forward it to?
C)If systemA (after the appointment is confirmed) want to inform SystemB (or SystemC) on the update of the status (to arrived), is it best to send it directly to B or C? Does the booked appointment have a call back URL in which it can be used there?
D) on each cascading scenario, is the transaction initiator needed to be in compliance with the other parties data dictionaries or its best that all three systems to talk in a common set of data dictionaries
Thanks.
Lloyd McKenzie (Aug 06 2020 at 01:34):
FHIR doesn't really tackle those things. FHIR defines an interface to talk to a server. If it ends up routing the request elsewhere, how it manages that and how it figures out who to route to aren't really FHIR's problem. (The exception is messaging which is specifically designed to enable routing and identifying an intended recipient other than the immediate recipient.) In your scenario, ideally the intermediary is capable of storing information about where data originated and can map between ids of different systems. How it does that - and how it stores that information - is outside FHIR's scope.
John Moehrke (Aug 06 2020 at 15:47):
very related to my question on id vs Reference vs Identifier vs fullUrl.... Seems one could put the .id generated by SystemC into the .identifier field with system=SystemC root; and value=id
Lloyd McKenzie (Aug 06 2020 at 17:09):
id is not unique within the server - you'd need the resource as well. Also, server URL + resource type doesn't necessarily connote the naming system for 'id', though it could.
Medi Harsini (Aug 07 2020 at 13:21):
I think I agree with John, I have done a POC on moving the .id to .identifier when the same concept is moved back and forth... Imagine you have got a TASK which needs to be send from systemA to B ... the initial transaction is going to create the .id generated by systemB in response to SystemA but if SystemA doesnt store it somewhere it has to make a request to find the .id first before it can make any updates. So transfering the .id to the identifier on the response (on this example) is quiet efficient. The above can be expanded across multiple systems.... I am surprised we didnt have in mind when domainresource was initially designed specially because this is not the case when in comes to Terminology systems. For the same concept you can store as many as you want Terminology system + Value when its transfered back and force but the same pattern is not considered for IDs.... I personally think some of the stuff we have in messagedefinition resource can be moved to META (similar to HL7 V2.0 header) ... Slightly deviated from the discussion but very much related
Last updated: Apr 12 2022 at 19:14 UTC
