A laboratory does not stop because a switch failed

A clinical analyzer does not care about your architecture. It runs a sample, produces a result, and transmits it over a serial link or a TCP socket — often through a converter box bolted to a wall, on a network segment maintained by a facilities team you have never met.

The gateway sits at that seam. Its job description is one line: never lose a result.

Persist the bytes before you understand them

The first thing the gateway does with an incoming frame is write it to local storage, raw and unparsed. Only then does it parse.

That ordering is the most valuable decision in the system, and the reason is worth being blunt about: the parser will be wrong at least once. A vendor ships an instrument with a field the documentation never mentioned. A firmware update changes a delimiter. A result arrives in a character set nobody planned for.

If parsing comes first, a parser bug loses data permanently. If the bytes are already on disk, the same bug is a fix and a replay.

The outbox, and why it is bounded

Parsed results go into an outbox. A dispatcher polls it and pushes upstream with retry and backoff. If the link is down, results keep being captured and are forwarded when it returns.

The bound matters as much as the retry. Without a maximum attempt count, one malformed message that the upstream will always reject sits at the head of the queue retrying forever, and every good result behind it waits. A queue that a single bad message can block is not a queue. It is a fuse.

Two directions, two delivery models

Results travel upstream asynchronously through the outbox. Nobody is waiting on them.

But an analyzer can also ask: I have this sample on the rack, what should I run on it? That is synchronous by nature. The instrument is holding a physical sample and waiting for an answer, and an outbox is exactly the wrong mechanism.

So the gateway has both paths, deliberately, and which one applies is determined by the protocol rather than by a configuration flag. Getting this wrong in either direction gives you a system that either loses results or stalls a rack.

Meet the instrument where it is

Vendor test codes differ by manufacturer and by model. Urine analyzers report semi-quantitative results as negative, one plus, two plus — meaningful to a technologist, useless to a numeric range check downstream.

Normalization belongs at the gateway, next to the instrument that produced the quirk, rather than spread through every system that eventually consumes the result. A new instrument is then a device profile: a code map, a result normalizer, a connection entry. Not a rewrite.

Test against a fake before you touch a real one

The gateway ships with a simulator that plays the analyzer side of the protocol. An integration can be built and proven on a laptop, so that the first time anyone stands in front of a live instrument, the remaining unknowns are electrical rather than logical.

This matters more in a laboratory than in most places. Bench time is expensive, the instrument is in clinical use, and “let us try it and see” has a patient attached to it.

The general shape

Capture locally, forward separately, bound your retries, and keep the layer that speaks the protocol pure and free of I/O so it can be tested exhaustively without a device present.

None of that is specific to laboratories. It is only that a laboratory is where you find out quickly whether you got it right.