## Day 1 10:00 — Handle partial failures in HL7 batch ingest
## Day 1 10:30 — Handle partial failures in HL7 batch ingest
## Day 1 11:00 — Handle partial failures in HL7 batch ingest
## Day 1 12:00 — Handle partial failures in HL7 batch ingest
## Day 1 14:00 — Handle partial failures in HL7 batch ingest
## Day 5 14:30 — Handle partial failures in HL7 batch ingest
I built the per-message outcome tracking and retry logic for HL7 batch ingest. Instead of a transactional all-or-nothing commit, the ingest loop now processes each message independently, recording its status (SUCCESS, RETRYABLE_ERROR, FATAL_ERROR) in a new `ingest_outcomes` table. Retryable failures (e.g., transient DB locks, temporary network issues) are retried up to 3 times with exponential backoff. Fatal errors (e.g., malformed HL7 structure) are logged and skipped, preventing a single bad message from halting the entire batch. I also added a migration for the outcomes table and a data-quality check script to verify that no message is silently dropped. I flagged to Dana Reyes that this changes the atomicity model, so we need to ensure the retry queue is durable before we deploy.