Detect and process partial-failure OperationOutcome NDJSON files returned in a completed FHIR Bulk Data $export manifest

Steps

1. After polling the kickoff request to completion (200 OK), parse the completion response body's 'output' array for successfully exported resource files and separately inspect the 'error' array, defined by the Bulk Data Access IG to reference OperationOutcome resources describing what went wrong.
2. Recognize that a non-empty error array can appear even when the overall export request 'completed,' signaling partial resource-level failures rather than a fatal request-level error.
3. Download each referenced error ndjson file using the same authenticated file-retrieval pattern as the main output files, then parse each line as an OperationOutcome resource.
4. Correlate each OperationOutcome's diagnostics back to the specific resource type or record that failed to export, and reconcile the exported record count against the expected patient/Group population to quantify the gap.
5. Build retry/alerting logic distinct from the happy path: partial failures should raise a data-completeness flag for the affected cohort rather than being silently ignored because the top-level job reported complete.
6. Confirm which version of the Bulk Data Access IG the server implements via its CapabilityStatement or documentation, since manifest field names and error-handling semantics can differ across IG versions.