FHIR Chat · on mobile

Hi folks. We have a use case where an Android mobile client needs to be populated with resources, like patient, location, organization, value sets, code systems. Is the Bulk Data API suitable for this use case? Any thoughts? @Jing Tang Note also that the Android clients may be on small pipes in middle- and low income countries.

Josh Mandel (Feb 23 2021 at 16:53):

This hasn't been a core use case guiding our design, but would love to get a sense of how you evaluate the "fit" -- and what alternatives you're considering (other than bulk export).

Josh Mandel (Feb 23 2021 at 16:56):

The "small pipes" constraint is obviously in tension with a "bulk data" requirement; like, if you want to get large sets of data onto a device that has only small pipes, you're going to be in for some pain. (Things that could help: ensuring your file server supports resumable downloads; being thoughtful about a server's individual .ndjson size limits; gzip-comprssing files, or ensuring your file supports dynamic compression negotiated over HTTP; exploring denser data formats like FHIR protobufs)

Richard Stanley (Feb 23 2021 at 18:52):

Thanks for the helpful response! I’ll ask @Jing Tang if he has more thoughts as this is in relation to the Google Android FHIR SDK

Jing Tang (Feb 24 2021 at 09:06):

Thanks @Richard Stanley and @Josh Mandel! This is super helpful. Is there a threshold for when the use of bulk data api becomes recommended/necessary? I'm guessing it's heavily context-dependent. But would love to hear what you think if you had to put a number on it.

We are currently using the restful search api for importing data from the server but imagine that might not be sufficient in the long run. Also, although there is this "small pipes" constraint and we design for poor connectivity and offline use, the initial sync of data from server to mobile is going to be done in a context with good connectivity at least. Just saying it's not like we're going to have people in areas with poor mobile connectivity downloading GBs of data.

@Josh Mandel I'm keen on the idea of using fhir protos as the wire format -- would love to explore and see how we can make some progress there.