Order acknowledgement & result lifecycle

1. Transmitted — bytes were sent. Not proof of receipt.
2. Commit acknowledged — the receiving system stored the message (HL7 CA). Application acceptance is still pending.
3. Application accepted — the laboratory system accepted the order (HL7 AA, or an explicit positive acknowledgement on the Lab Contract).
4. Accessioned / specimen accepted — the laboratory assigned an accession and accepted the specimen.
5. Result received — preliminary, final, corrected or amended, according to the reported status.
6. Released — the laboratory authorized release; only released results reach the Partner API.

• HL7 AE, AR, CE and CR are rejections; CE and CR are never treated as acceptance.
• A corrected or amended result is a new version. Earlier released versions are kept, never overwritten.
• Duplicate result deliveries are deduplicated against the canonical result revision.

Keep the original order and message correlation when investigating. A stuck sending row after a crash is also ambiguous: do not create a new idempotency key or requeue it blindly. Laboratory IT and an authorized operator must confirm the original outcome.

In native REST/FHIR source paths, an order timeout, dropped connection or HTTP error after sending becomes delivery unknown and is not retried automatically. The executable HTTPS/JSON worker still retries classified HTTP, timeout and network failures; it does not provide this same safety guarantee. Preserve the original order and reconcile uncertain outcomes with the laboratory.

Native paths distinguish provable pre-send refusal from uncertain delivery. The HTTPS/JSON Lab Contract retains bounded retries up to 5 attempts and may mark a refused sent-state write retryable; this unresolved safety gap requires release review.