fhir-server | A fast , open source , HL7 FHIR server | Data Manipulation library

As indicated in the spec (https://hl7.org/fhir/uv/bulkdata/export/index.html#bulk-data-status-request) you should store the Content-Location return header of the $export request. That is the location where you can check status of the export and see the URLs of the resulting files.

$import is a draft spec and it is not supported (yet) on the Azure API for FHIR.

For a single observation type and a single subject, if the observations are being made on a regular periodic basis, you can use the SampledData data type as the Observation.value. Typically that's for things like EKGs, fetal heart rate monitors, etc. which are sampling on a frequent basis, but nothing stops you from having a sampling period of an hour. However, if you don't have regular sampling, you must capture each as a distinct Observation. The reason is that we need to be able to extract the data however the user chooses to query it. The data needs to come in with the same sort of fine-grained organization that it might later need to go out. You might look at the Bulk Data API which uses LD-JSON to allow more efficient processing of large volumes of data.

This question seems to have considerable overlap with your other question. You would use $export to export the data from the FHIR API to some other form of storage, e.g. BLOB storage and then orchestrate whatever pipeline makes sense from there.

Behind the managed FHIR API there is a database, of course, but there is no direct access to that data store in the managed service. If you want to look at the database schema, I would suggest having a look at the open source version of the service (https://github.com/Microsoft/fhir-server). However, I would recommend against taking any specific dependency on the schema as it may change.

When you issue the $export request, the response should have a Content-Location header with a URL to the status document for the export job. If you check that location should should see a status of what has been exported and a location of the files.

It looks like you have not added the (correct) object id of the registered application. Importantly, the application registration has an object id, but so does the service principal. It is the application id for the service principal you are looking for.

Check instructions here:

https://docs.microsoft.com/en-us/azure/healthcare-apis/find-identity-object-ids

You can find it the service principal object id with PowerShell: