Test hospital interfaces for failed and repeated messages
For CIO/CTO / digital programme owner · Plan implementation
TL;DR — what you’ll learn
- Define the business outcome and its identifiers before selecting an interface mechanism.
- A timeout can leave the destination outcome unknown; it does not prove failure.
- Test duplicates, stale corrections, denied access and partial failures.
- Accept an interface only when missing events and recovery work have accountable owners.
A hospital's source system sends a receipt to the ERP. The ERP accepts it, but the response is lost. The integration retries and creates a second receipt. Both applications behaved according to their local screens, while the hospital gained a duplicate transaction.
Hospital software integration needs a contract for identity, state and recovery. Specify what business event is being transferred, how the destination recognises it and how the team establishes an uncertain result before repeating a write.
Define the transaction before the transport
Use one receipt interface as an illustrative pilot. Source event R-51 version 1 represents one approved receipt line. The contract includes its source system, event ID, version, item, unit, quantity, location, approval reference and intended destination action. A correction carries a relationship to the earlier event.
An API, event stream or file is a transport choice. It does not automatically provide the required business semantics.
Scroll horizontally to see all columns.
| Mechanism | Useful question | Recovery dependency |
|---|---|---|
| API request | Does the destination support lookup or duplicate-safe creation? | Establish outcome after a timeout |
| Event feed | How are identity, ordering and redelivery handled? | Reconcile replay and stale events |
| File import | How are file identity, rows and partial acceptance reported? | Resume without re-importing accepted rows |
For a FHIR R4 interface, HL7’s HTTP specification describes how servers declare supported resources and interactions in a CapabilityStatement. Inspect the actual destination’s declaration and vendor agreement; the standard does not prove that every interaction is implemented there.
Treat an unknown outcome as its own state
After the lost response, mark R-51 as “outcome unknown” until a supported destination query, reconciliation report or authorised investigation establishes the result. A network retry with a new business identity defeats duplicate protection.
If the destination supports an idempotency mechanism, confirm its key scope, retention and conflict behaviour. If it does not, determine whether a stable external reference and reliable lookup can support the required control. Where neither is available, a reviewed manual boundary may be necessary. Do not promise exactly-once delivery from transport retries alone.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepAuthorised source event and stable identity
- B · StepValidate mapping and permissions
- C · StepSend supported destination operation
- D · DecisionBusiness outcome established
- E · StepStore destination reference
- F · StepOwned exception with reason
- G · StepReconcile destination before retry
- H · DecisionPrior acceptance found
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Authorised source event and stable identity | Continue | B: Validate mapping and permissions |
| B: Validate mapping and permissions | Continue | C: Send supported destination operation |
| C: Send supported destination operation | Continue | D: Business outcome established |
| D: Business outcome established | Accepted | E: Store destination reference |
| D: Business outcome established | Rejected | F: Owned exception with reason |
| D: Business outcome established | Unknown | G: Reconcile destination before retry |
| G: Reconcile destination before retry | Continue | H: Prior acceptance found |
| H: Prior acceptance found | Yes | E: Store destination reference |
| H: Prior acceptance found | No and retry permitted | C: Send supported destination operation |
| H: Prior acceptance found | Still unclear | F: Owned exception with reason |
Validation should reject a missing unit or unauthorised site before creating a destination transaction. A message's content cannot grant itself permission to write.
Test a correction arriving out of order
Suppose R-51 version 2 corrects the quantity and arrives before a delayed copy of version 1. The destination must apply its agreed version policy rather than treating arrival order as business truth. Preserve the stale event and its disposition for investigation.
With a partially accepted file, record accepted and rejected rows separately. If nine rows succeeded and one failed, replaying the whole file without row-level identity can duplicate the nine. Reconcile counts and business totals in addition to technical acknowledgements.
Treat identifiers, units and domain meanings as mapping inputs supplied by their responsible owners. Test ambiguous mappings as failures requiring review. This integration guide does not establish clinical-code equivalence, patient identity or financial posting rules.
Operate the exception path
Use synthetic payloads for recovery tests. Before handling real data, obtain the approved access, logging, retention and incident design from security and privacy owners. The proposed error queue needs a source reference, owner and permitted next action, not unrestricted copies of sensitive payloads.
The challenge set should include duplicates, a lost response, stale updates, invalid mappings, denied permissions, missing events and destination downtime. Require one accepted business outcome per intended event, no unauthorised writes in the test set and an owned record for every rejection or uncertainty.
Measure source-to-destination completeness, unresolved age, recovery effort and duplicate outcomes. Pause the writer if the reconciliation cannot explain its effects. Reconcile manual actions before resuming; use supported compensating corrections for accepted mistakes rather than deleting history.
Reconcile business outcomes with the source inventory
For an illustrative batch of 50 intended events, the reconciliation might show 47 confirmed accepted, two confirmed rejected and one still unknown. Those states account for all 50, but the batch is not fully accepted. The unknown event could already exist at the destination; the figure is a count of established outcomes, not proof that exactly 47 records exist there.
Reconcile identities as well as counts. Two events accidentally assigned the same destination reference can leave totals apparently correct while one source event is unrepresented.
Scroll horizontally to see all columns.
| Failure introduced | Evidence required to pass the case |
|---|---|
| Response lost after acceptance | Lookup establishes the existing outcome; no extra business record |
| Version 1 arrives after version 2 | Agreed stale-event handling preserves the accepted correction |
| File accepts nine rows and rejects one | Per-row outcomes allow recovery without re-creating the nine |
| Mapping is structurally valid but the unit is wrong | Domain validation rejects or routes the event before an unauthorised result |
| Writer loses permission | Denied action stays denied; credentials are not broadened automatically |
Start with dry-run validation or a controlled test destination, then use a narrowly authorised writer. Agree who pauses the interface when reconciliation is incomplete and who approves resumption after manual work has been reconciled. The vendor must demonstrate the actual lookup, replay and correction mechanisms; a generic retry library is not that evidence.
This acceptance contract begins after the system-ownership decision and software evaluation. It proves the behaviour of one agreed handover, rather than selecting the whole hospital platform.
Next actions
- Agree event identity, versioning and the business acceptance state for one interface.
- Obtain vendor evidence for duplicate protection, lookup and corrections.
- Run the failure set and assign operational ownership before enabling production writes.
Discuss this workflow
Discuss an integration acceptance assessment for one interface, including a lost response, duplicate event, stale correction and manual recovery.
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- Integration architect and both system vendors: Current capability/API specification and versioned tests; confirm idempotency key scope and retention rather than assuming exactly-once delivery.
- Relevant clinical informatics and business process owners: Approved field/unit/terminology mappings and independently reviewed expected outcomes.
- Security lead and privacy/legal owner: Approved access/logging design, current retention/incident applicability review and denied-access test.
References
- HL7 FHIR R4 HTTP specification — Supported-interaction discovery and version-specific API concepts; does not guarantee any hospital system's implementation.
Topics: hospital software integration · hospital API integration · HIS interface testing · healthcare integration exception handling