Interface NormalizedOptions

The original export manifest will have an url property for each file, containing the source location. It his is set to true, add a destination property to each file containing the path (relative to the manifest file) to the saved file.

Only needed if destination points to S3

Example: us-east-1

Only needed if destination points to S3

Examples:

• s3://bucket-name/optional-subfolder/ - Upload to S3
• ./downloads - Save to local folder (relative to the config file)
• downloads - Save to local folder (relative to the config file)
• /path/to/downloads - Save to local folder (absolute path)
• file:///path/to/downloads - Save to local folder (file url)
• http://destination.dev - POST to http
• http://username:password@destination.dev - POST to http with basic auth
• "" - do nothing
• "none" - do nothing

If this is set to false, external attachments found in DocumentReference resources will not be downloaded. The DocumentReference resources will still be downloaded but no further processing will be done.

FHIR server base URL

Sometimes a server may use weird names for the exported files. For example, a HAPI server will use random numbers as file names. If this is set to true files will be renamed to match the standard naming convention - {fileNumber}.{ResourceType}.ndjson.

If an attachment can be inlined (based on its size and the value of the inlineDocRefAttachmentsSmallerThan option), then its mime type will be compared with this list. Only files of listed types will be inlined and the rest will be downloaded into "attachment" subfolder.

In DocumentReference resources, any attachment elements having an url (instead of inline data) and a size below this number will be downloaded and put inline as base64 data. Then the size property will be updated and the url will be removed.

If true, adds handling=lenient to the prefer request header. This may enable a "retry" option after certain errors. It can also be used to signal the server to silently ignore unsupported parameters.

While parsing NDJSON files every single (non-empty) line is parsed as JSON. It is recommended to set a reasonable limit for the line length so that a huge line does not consume the entire memory.

If the server reports the file count in the export manifest, verify that the number of resources found in the file matches the count reported by the server.

If true, verifies that every single JSON object extracted for the NDJSON file has a resourceType property, and that this property equals the expected type reported in the export manifest.

How many downloads to run in parallel. This will speed up the download but can also overload the server. Don't be too greedy and don't set this to more than 10!

If this is true, attachments of type PDF that are being inlined will first be converted to text and then inlined as base64

The private key used to sign authentication tokens

If the server does not provide Retry-after header use this number of milliseconds before checking the status again

In some cases it might be useful to also save the export manifest file along with the downloaded NDJSON files.

The Bulk Data server token URL ("none" for open servers)