Considering the additional information in your comments i'd go for a solution like this:
Since your applications are both running in an intranet i'm assuming the availability of your service is more or less guaranteed.
App A - Running locally, used by one user per device
I'm not completely sure how to get the data from App A since you mentioned that you don't have direct access to the sqlite-db. I assume there is some way of accessing the data using something like an API,..?
Since your App A stores it's data in a sqlite db anyway, i wouldn't go for a local export to flat files. In my understanding you would be able to extract data from App A's Db anytime you want to. In case of a failure during sending the data you could rerun your export again without acctualy losing data.
Every time the export is started (triggered by App A saving?), send the data directly to your service. Verify if the service received your full set of data using a checksum or something similar.
I'd try to shrink the functionality and complexity of your code on the devices running App A to a minimum since the deployment on a uncertain or growing amount of devices can be time consuming and challenging.
App B
The App B doesn't need to know about your export/import process, service or App A.
Service
Should accept data sent from any application knowing about the service and having the permission to do so.
The service accepts the data and processes them in one of the following ways:
Option 1
It directly writes the received data to App B's database and confirms the reception. Writing the data directly could lead to some issues like User X loads data regarding patient 1, the service receives a new set of data, User Y gets patient 1s data afterwards. They'll now get a different state of data. You would have to deal with this for example by notifying each client about updated data and reload every App B instance accessing data loaded before the service updated them.
Another reason for not writing data directly to App B's database could be the amount of devices and sent data which needs to be written by your service blocking your App B's database while doing so.
Option 2
It saves to received data to his own database, storing them temporarily. In case your imported data is not needed immediately you could fetch the data to App B's database every night or so. This would guarantee your users using App B to work with the same state of data the whole day, even though they wouldn't use up-to-date data.
Option 3
In case the amount of data sent to your service gets too big to proceed it immediately you could attach a queue to Option 2 to avoid a blocked service.
Conclusion
Since there has been a few ambiguities like how important it is for the data in App B to be up-do-date i'd go for service option 2.
