Teaching an integration by tracing a missing result

“The result is missing” sounds like one problem. In an integrated laboratory workflow, it can describe several different failures: an order never reached the processor, no sample was registered, laboratory work is incomplete, or a verified result has not made it back to the requesting system.

That made it a useful starting point for the ZanLIS developer training I facilitated. Following a request required participants to connect the architecture to something an actual user needed.

First, make the workflow real

The January 2026 workshop included local environment setup, laboratory workflows, and end-to-end integration simulation. Participants worked through sample receipt, verification, rejection, and cancellation, alongside processor setup and requests sent through integration tools.

That groundwork mattered because a status in one system cannot be interpreted without knowing the workflow it represents. A registered sample is not necessarily a received sample. A verified result is not necessarily a delivered result.

The February follow-up brought those pieces into investigation: tracking orders across the laboratory system, processor, and integration layer, then distinguishing operational issues, data problems, and code defects.

Ask for evidence and a next action

The order-tracking exercise asked participants to record three things: status, observation, and way forward.

Those small headings imposed useful discipline. A status described what the system recorded. An observation explained what the developer had found. The proposed next action had to follow from that evidence.

Consider an illustrative case: a sample is verified in ZanLIS, but the requesting facility cannot retrieve its result. The investigation might proceed through these questions:

1. Can I connect the source order to the correct processor request and laboratory sample?
2. Does the laboratory record establish that verification happened?
3. Did the processor receive and accept the outcome?
4. What evidence exists for delivery to the requesting system?

The answers determine where to continue. Repeating laboratory verification makes little sense if the outcome was already accepted and the failure is in delivery. Retrying delivery makes little sense if the incoming outcome was rejected for a mismatch.

This example describes the investigation method, not the recorded resolution of a particular training case.

Real incidents made the boundaries visible

The workshop also included code review and production troubleshooting. The copied-sample incident was part of that work: a copied sample retained integration identifiers, allowing a different test's outcome to be associated with the original request.

Understanding that failure required more than finding a log line. The group needed the laboratory's copying workflow, the integration's matching assumptions, and the distinction between an external order identity and a newly created sample.

I used the system I had built and maintained as the basis for participants’ exercises. The useful evidence of learning was what they could trace, explain, change, and review during those activities. The workshop records do not establish a measured improvement in independent delivery speed or competence.

A support question can teach the architecture

For me, the value of this exercise was that it gave the architecture a route through it. Instead of remembering components in isolation, developers followed one piece of work and asked what each boundary guaranteed.

A justified escalation also counted as a useful outcome. Sometimes the next step belonged to laboratory staff, another integration team, or someone with production access. Identifying that owner and carrying clear evidence was part of learning to support the system.

Whether that practice translated into sustained ownership was a separate question, which became central to the later handover review.