Filter content referenced on the Composition or IG using the _lastUpdated during download

[dubdabasoduba]

Describe the feature request.

• Currently, the configurations are re-downloaded every time a user logs in with their username and password. While this ensures we fetch updated configurations, it also results in re-downloading content that hasn’t changed, impacting sync time during subsequent syncs.
• This ticket aims to introduce a lastConfigSync timestamp, which will work alongside the _lastUpdated property on FHIR resources.
  • The lastConfigSync timestamp will have the following characteristics:
  • It will be updated each time the content download is completed successfully.
  • When available, it will be included in subsequent content requests after login.
  • It will be stored in the application’s shared preferences.

Acceptance criteria

• Always save the lastConfigSync timestamp everytime the configs are complete sync successfully
• Always attach the lastConfigSync to requests for content referenced on the Composition or IG
• Correctly store the lastConfigSync on the application share preferences

Implementation plan (For Engineers)
The plan for implementing the solution e.g. via a description or a check list for the various ordered tasks that will need to be completed.
i.e. Describe how you intend to solve the problem

[dubdabasoduba]

@ellykits @pld please review this

[pld]

One issue is how to set lastConfigSync, pretty sure we'd need to set this with a time that is provided by the remote server, since I believe that is also where the _lastUpdated is set.

Is there a way that the current server time is already being set back? It might be somewhat cludgy to add that as a returned value from the remote server.

An alternative approach would be to take the largest timestamp in _lastUpdated from the synced resources and use that as the lastConfigSync timestamp. Then we'd make sure we are using the same timezone/etc the server is. If we use this approach we'd have to make sure we use a strict > comparison, as opposed to a >= comparison.

[ndegwamartin]

One issue is how to set lastConfigSync, pretty sure we'd need to set this with a time that is provided by the remote server, since I believe that is also where the _lastUpdated is set.

Is there a way that the current server time is already being set back? It might be somewhat cludgy to add that as a returned value from the remote server.

An alternative approach would be to take the largest timestamp in _lastUpdated from the synced resources and use that as the lastConfigSync timestamp. Then we'd make sure we are using the same timezone/etc the server is. If we use this approach we'd have to make sure we use a strict > comparison, as opposed to a >= comparison.

I believe this is how the FHIR SDK does it for the data FHIR resources - https://github.com/google/android-fhir/blob/master/engine/src/main/java/com/google/android/fhir/sync/download/ResourceParamsBasedDownloadWorkManager.kt#L115-L127

[pld]

cool sweet, great find, yea let's follow the exact same logic, that's the alternative approach I noted

[dubdabasoduba]

@Aleem92 I just tested the HAPI API on the current version we use.

_lastUpdated doesn't seem to work when performing GET {{base_url}}/Composition/<uuid> however it works on {{base_url}}/Composition?_lastUpdated=<date>

e.g https://{{base_url}}/fhir/Composition?_lastUpdated=gt2025-04-18

[dubdabasoduba]

@pld @ndegwamartin We might have to pause this until we test it on the latest version of HAPI. If still doesn't work then we close the ticket

[Aleem92]

@Aleem92 I just tested the HAPI API on the current version we use.

_lastUpdated doesn't seem to work when performing GET {{base_url}}/Composition/<uuid> however it works on {{base_url}}/Composition?_lastUpdated=<date>

e.g https://{{base_url}}/fhir/Composition?_lastUpdated=gt2025-04-18

Thanks for confirming this, @dubdabasoduba. I had raised this issue regarding {{base_url}}/Binary/<uuid>?_lastUpdated=<date> not working as expected. I appreciate you taking the time to test and confirm the behavior on the ticket.