Hi Ashok,

sorry for the late response. That get me a little further. The approach of ordering by date seem to work only as long as all of the resources have a period.start and period.end provided. In my scenario the most acutal encounter doesn´t have an period.end set since it has not yet ended. The field period.start of one encounter is the the period.end of it´s predecessor.  Can you confirm that behaviour of the FHIR server if no period.end is set? If so what would be your approach?

best regards,
sebastian

Hi Ashok,

thank you for the response. This url is the exact same syntax that I used above (possibly my links contracted by the UI and therefore not fully visible). Anyway in my case there is no filtering applied at all and simply all encounters are returned regardless of the date. Could you post your encounter resources he used for testing so I can test if it is a FHIR server version specific issue?

best regards,
Sebastian

Hi Guillaume,

thanks for the example. As pointet Customer runs version 2022.1.3 insgesamt of 2023.x is there any way to accomplish this in Version 2022.1? From your second call i‘ve noticed That the resources were updated despite no modificatons in the resource contents were made. Is there any way to update only when modifications were made?

best Regards,

sebastian 

That adjustment didn´t work either. Maybe there need to be another adjustment in the bundle to supoort my scenariao? This is recieving the bundle (i can manipulate it) send it to the InterSystems FHIR server and conditionaly create and/or conditionaly update the resources in the FHIR server.

How would you (based on the organization scenario) would your bundle look like?

Hi Tani,

The Support for conditional update for a ressource seems to exists also in iris for health Version 2022.1.3 (at least docs state this). Van you confirm that? Bades in josephs example from above what could the conditional Update on Patient ressource Look Like? Asfaik the conditional update could insert a non existing resource as well.

best Regards,

sebastian

Disabling trace Events on an active Message Router requires the Router to be stoppen and started again. After That no trace events will be logged anymore. You also should have rule logging setting of Router in mind when doing so. When starting/stoppen the Message Router consider its pool size setting to avoid side effects such as stop of Ens.Actor queue.

Hi Craig,

thank you for your response. So first of all good to hear that I am not the only one with this kind of questions. I assume you don´t configured an OAuth Client via SMP directly but instead do the  invocation of the API endpoint to get the token directly in the operation - therefore you should not use any %OAuth... framework-functionalities from within the operation - am I correct?

It would be very interesting to here from InterSystems what would be the best practise here. Anyway this should work. Could you supply me with an example of how you implemented the GetBearerToken() method?

best regards,

sebastian