Raw Protocol Data: Proving Where Every Lab Result Came From

A parsed lab result looks like a fact. It has a patient, a specimen, an analyte, a value, a unit and a timestamp, and it sits in a database row that carries all the visual authority of a fact.

It is not a fact. It is an interpretation — the output of a piece of software reading a stream of bytes from an analyzer and deciding what those bytes meant. Most of the time the interpretation is correct, which is why the distinction rarely comes up. It comes up on the day somebody asks whether a specific number was really what the instrument said, and the honest answer, if the original bytes were discarded, is that nobody can tell you.

Storing raw protocol data alongside every parsed result closes that gap. This post covers why a parsed value alone is insufficient evidence, what retention actually involves, how custom parameter mapping interacts with it, and what accreditation reviewers ask for.

Why a Parsed Result Is Not Enough Evidence

Parsing is a chain of decisions. An ASTM E1394 result record arrives as delimited fields; the parser has to know which field holds the test identifier, which holds the value, how the instrument encodes units, what its flags mean, and how it represents a result that is out of range or unreadable. Every one of those is a rule, and rules can be wrong in ways that produce plausible output.

Three realistic ways a parsed value can be wrong while looking entirely normal:

• Field offset. An analyzer firmware update adds a field. Every field after it shifts by one. The parser keeps reading position seven, which is now a different quantity. The values are still numbers in a believable range.
• Unit assumption. The instrument reports in one unit; the mapping assumes another. The number is real, the magnitude is wrong by a factor, and nothing in the record announces it.
• Dropped qualifier. The instrument flagged a result as suspect or diluted. The parser did not carry the flag through. The value arrives downstream looking clean.

In each case the parsed row is internally consistent and reviewable, and reviewing it tells you nothing, because the error is not in the row — it is in the step that produced the row. The only artefact that can settle the question is what the analyzer actually transmitted.

Storing the Frame Beside the Result

LISBridge retains the raw instrument protocol data alongside every parsed result. The parsed record is what gets delivered to the LIS and what clinicians see; the raw frame stays with it as the source document.

Three things make retention practical rather than a storage problem:

Volume is small. An ASTM or HL7 frame is text, typically measured in hundreds of bytes to a few kilobytes. A busy lab generates a rounding error against the images and documents already stored in any clinical system.

Deduplication is indexed. Analyzers retransmit. An instrument that does not receive an acknowledgement will send the same frame again, and a naive store would accumulate duplicates that make a query for "what did the analyzer send" ambiguous. LISBridge maintains a composite index for raw data deduplication so that a retransmission is recognised as the same frame rather than filed as a second one.

It stays local. Raw frames contain patient identifiers, so where they live matters as much as that they exist. LISBridge is a desktop application with local storage — the raw data does not traverse a vendor's cloud to be retained. That property is the same one described under data security, and it is what makes retention compatible with a HIPAA-conscious architecture rather than in tension with it.

The practical shape of this: for any result, you can ask what the instrument sent, and get bytes rather than a reconstruction.

Custom Parameter Mapping: When the Names Disagree

There is a second traceability problem that raw retention alone does not solve, and it is the one labs hit first.

The analyzer's field name and your LIS field name will not match. The instrument calls something WBC; your LIS expects WBC_COUNT. It reports a differential the LIS wants split across six fields. It emits a manufacturer-specific research parameter your LIS has no slot for at all. Multiply by the number of instruments in a mixed-vendor lab and the mapping layer becomes the place where meaning is assigned — and therefore the place where meaning can be assigned wrongly.

Historically this was vendor work: raise a ticket, describe the mapping, wait for a build. That is slow, and it puts the record of why a field maps the way it does inside a vendor's support system rather than in your lab.

LISBridge treats custom parameters and parameter mappings as first-class records you configure yourself. A lab can map any analyzer parameter to any LIS field without custom programming. For traceability, the important consequence is that the mapping is data — it exists, it is inspectable, and it has a history. When a result looks wrong, you can examine three layers rather than guess: the raw frame the instrument sent, the mapping rule that was applied, and the parsed value that came out. An error lives in exactly one of those, and having all three makes finding it a ten-minute job instead of a week of correspondence.

This is the same layering described in data parsing, viewed from the evidence side rather than the throughput side.

Traceability Is the Precondition for Analytics

Labs increasingly want to do something with their accumulated data — trend analysis, turnaround measurement, cross-instrument comparison, and lately machine learning on historical results. All of it depends on a property that is easy to assume and hard to retrofit: knowing what the data means.

If a mapping changed eighteen months ago and nothing recorded it, then a column in your historical data contains two different quantities and there is no marker at the boundary. A model trained on that learns an artefact. A turnaround report that spans the change compares two different measurements. The analysis is not wrong because the method was bad; it is wrong because the provenance was unknown.

Raw retention plus explicit mapping records give a dataset the property that makes it usable: for any value, you can establish what produced it and under which rules. That is unglamorous infrastructure, and it is the difference between a data warehouse you can build on and one that quietly produces confident nonsense.

What Accreditation Reviewers Actually Ask For

Accreditation frameworks vary, but the questions converge on a short list. Reviewers are consistently interested in whether a result can be traced from report back to instrument, whether the interface between instrument and LIS has been validated, whether changes to that interface are documented, and whether a discrepancy can be investigated after the fact.

Note what is not on that list: nobody asks to see your parser's source code. What is asked for is evidence, and specifically evidence that exists independently of the system whose behaviour is in question. A parsed value that is only stored as a parsed value cannot serve as evidence about the parsing — it is the output being questioned.

A lab that retains raw frames and explicit mapping records can answer a traceability question by showing the chain. A lab that retains only parsed values answers it with a description of how the system is supposed to work, which is a substantially weaker position and reads that way in a report. The same reasoning applies to a clinician query about an implausible result and to a dispute months later: the winning move is having the original, and there is no way to acquire it retrospectively.

This connects directly to the transcription and accreditation questions covered under HL7 and ASTM support — automated capture removes transcription error, and raw retention is what lets you demonstrate that it did.

FAQ

How much storage does raw retention require?

Very little. Protocol frames are text — hundreds of bytes to a few kilobytes each. Even a high-volume lab accumulates a small fraction of what a single day of clinical imaging occupies.

Does storing raw data create a privacy problem?

It requires the same care as any patient data, which is why the storage location matters. LISBridge keeps raw frames in local storage on the machine running the software rather than transmitting them to a vendor-operated service, so they fall under the same controls as the rest of your local clinical data.

Can I search the raw data?

Yes. Raw payloads are stored indexed rather than as opaque blobs, so they can be located by specimen and result rather than only by scanning.

What if the instrument sends the same result twice?

Retransmission is normal — an analyzer that does not see an acknowledgement resends. Composite indexing on the raw data recognises a duplicate frame as the same frame, so retransmissions do not create phantom second results.

Does this apply to file-based analyzers as well as serial and network ones?

Yes. The principle is transport-independent: whatever the instrument transmitted is retained, whether it arrived over RS-232, TCP/IP, or as a file over FTP, FTPS or SFTP.

Start your free trial — no credit card required. lisbridge.com/pricing