Form: Interface Fault Isolation and Vendor Dispute Record

This is a ready-to-use form. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Complete this form when an interface or integration test fails and it is not immediately clear which system, or which vendor’s component, caused the failure. One form covers one interface failure. It is a companion to Test Script: Interface and Integration, which executes the test, and to Test Failure Scope and Impact Assessment, which this form feeds once fault is isolated or the dispute is documented. See Managing test failures during validation for the full disposition logic this form supports.

Why this form exists

An interface connects two systems, so an interface failure always has at least two plausible owners, and sometimes a third if a vendor-supplied middleware component sits between them. The instinct on each side of that boundary is to check its own logic, confirm it looks correct, and conclude the problem is on the other side. Both sides can honestly believe that and both cannot be right, and sometimes neither is: the fault sits in the transport or the mapping between them.

This form forces the isolation question to be answered from boundary-level evidence, pulled from each side independently, before anyone’s explanation is accepted. Where a vendor is involved and disagrees with the finding, it records both positions and the evidence behind each, so the record does not quietly adopt whichever explanation arrived first. It also keeps the one fact that survives any fault argument in view: the interface failed its acceptance criterion during validation, and that has to be dispositioned no matter who is ultimately responsible.

Field table

1. Header

2. The interface and the failure

Record the initial explanations here specifically because they are not yet evidence. The point of the next section is to replace them with something checked.

3. Boundary-level evidence (both sides independently)

Pull the transaction as it existed at each side of the boundary, before either system’s business logic has touched it. A finished screen or report in System B tells you what System B did with the data, not what it received.

4. Fault isolation finding

5. Vendor position and dispute record

Complete this section whenever a vendor’s stated position differs from the finding in section 4. Document both positions. Do not resolve a dispute by adopting either position without the evidence behind it.

Where the dispute remains unresolved at the time this form is closed, say so plainly in the conclusion (section 9). An honestly documented disagreement is a stronger record than one that quietly picks a side.

6. Classification and escalation

Apply the same classification logic used for any test failure, independent of fault attribution. Fault location affects who fixes it, not whether it escalates.

Where fault is disputed or cannot be isolated, classify as a system defect for tracking purposes rather than leaving the item unclassified. An unclassified interface failure is the one most likely to be forgotten between quality systems.

7. Interim control / risk acceptance (if the system must go live before resolution)

8. Required actions and retest

9. Conclusion

<<FILL: three to six sentences. State where the fault was isolated to and on what evidence, whether the vendor agreed or disputed it, how the interface test case is dispositioned regardless of fault attribution, and what retest or interim control follows.>>

10. Approvals

11. References

21 CFR 211.192, investigation of unexplained discrepancies, extended here to a discrepancy spanning two systems rather than one. 21 CFR Part 11, where the interface carries electronic records or signatures. EU GMP Annex 11, Computerised Systems (2011), on interfaces between computerized systems and the assessment of deviations found during validation. EU GMP Annex 15, Qualification and Validation (2015), on documenting and justifying deviations from the validation protocol. ICH Q9, Quality Risk Management, for the risk basis of an interim control or risk-acceptance decision.

Confirm the current version and clause numbers of each reference before issue.

Filled specimen

The following shows the form completed for an example interface failure found during OQ between a LIMS and a vendor-supplied automated microbial identification system. The company, system, and numbers are illustrative.

Header and interface

Boundary-level evidence

Fault isolation finding

Vendor position and dispute record

Classification and escalation

Interim control

Required actions and retest

Conclusion

The intermittent truncation of organism names during MID-to-LIMS result transmission was isolated to the MID vendor’s result-export routine, which switches to byte-counted truncation under a Latin-1 encoding fallback triggered by certain multi-byte characters, confirmed by transmission-log evidence captured at the sending boundary before LIMS received anything. The vendor initially attributed the issue to LIMS based on an application log that did not reflect the transmitted value; providing the vendor with transmission-level evidence and a simplified reproduction resolved the disagreement, and vendor engineering confirmed the mechanism as a known, previously undisclosed firmware behavior. The interface test case remains FAIL pending the vendor’s firmware patch and a targeted re-test against organism names carrying the same character class, with an interim manual-confirmation control in place for the remainder of qualification.

Notice what the boundary-level evidence did here. The vendor’s first explanation was not dishonest, it was simply drawn from a log that could not see the problem. Pulling the transmission record rather than the application record is what turned “our logs show it was fine” into a confirmed, specific, fixable defect, and the interface stayed FAIL on the record the entire time that was being sorted out.

Common inspection findings this form prevents

• A vendor’s self-report accepted as root cause with no independent evidence pulled from the actual interface transaction.
• An interface failure left unclassified and untracked while two parties argue informally about whose system is at fault.
• A test case quietly marked PASS, or simply left without a clear FAIL disposition, because the root cause investigation was still unresolved.
• “Waiting on the vendor” as a permanent status with no assigned owner, no target date, and no interim control.
• A disagreement with a vendor resolved by adopting their explanation without checking it, with no record of what the internal team’s own evidence showed.
• Evidence pulled only from a finished screen or report on one side, rather than from the boundary itself, so the fault is attributed to the wrong system.

How to adapt this form

1. Name your actual boundary evidence sources in section 3 for each interface type you use: a message queue, a file drop with a processing log, an API gateway log, a database staging table. The principle (pull it before either system’s business logic touches it) stays the same across all of them.
2. Set your vendor escalation path and the support tier that can actually produce transmission-level evidence, not just an application-level status. Tier 1 phone support rarely has access to what section 3 needs.
3. Point section 6’s classification questions at your own GxP-relevance and data-integrity criteria so this form’s classification stays consistent with the main test incident classification table.
4. If your quality agreement or vendor contract specifies a defect-notification or dispute-resolution timeline, reference it directly in section 5 so the target date is contractual, not just aspirational.
5. Where an interface is shared across more than two systems, or by more than one vendor, duplicate section 3 for each additional boundary rather than forcing a three-way comparison into a two-column table.