Most healthcare AI demos die at the LIS boundary

Every healthcare AI demo I’ve watched in the last two years has the same shape.

A clean screen. A patient context loaded from a JSON file. A model that produces a recommendation in 800ms. Smiles all around. Funding round.

Then someone asks the question that ends the demo:

“Cool — where does the lab result actually come from in production?”

Silence. Sometimes a hand-wave at “the EHR.” Sometimes a slide titled Integrations (Coming Soon). Sometimes, mercifully, an honest “we haven’t figured that out yet.”

This is what I call the LIS boundary — the line between a clinical AI that works in a slide and a clinical AI that works on a Tuesday afternoon. Almost nothing crosses it cleanly.

The boundary is not a technical problem. It is a translation problem.

Every Lab Information System is, in practice, a small custom country. It has:

• Its own analyte codes (sometimes LOINC, often a local mapping someone built in 2009)
• Its own units (mg/L vs mg/dL vs µmol/L for the same analyte, sometimes within the same lab between two analyzers)
• Its own concept of a “result” (preliminary, corrected, final, amended, archived, suppressed)
• Its own concept of a “patient” (different ID between the LIS, the HIS, and the billing system)
• Its own deeply held belief about what constitutes a “panel”

Your model does not care about any of this. Your production system will be eaten alive by all of it.

What I look for before I trust a clinical-AI claim

When someone shows me a clinical decision support system and says it “works in production,” I ask four questions in this order. They tell me almost everything.

1. Where does the input come from — at what latency, in what format, on what schedule?

If the answer is “we pull from the LIS API every 5 minutes” — fine, but now your CDS is at minimum 5 minutes behind reality, and you’ve just built a polling system on top of a database that was never designed to be polled. Real-time clinical AI almost always means an HL7 v2 feed, a FHIR subscription, or a database trigger — each with its own failure modes and its own political cost inside the hospital.

2. What is the system’s behavior when the input is malformed?

In a real LIS, malformed inputs are not edge cases. They are Tuesday. A result comes in without a unit. A patient identifier doesn’t resolve. A panel is reported with three of four expected analytes and the fourth is *. If your AI’s answer is “we throw a 400,” you don’t have a production system; you have a demo with extra steps.

3. How does a clinician override the AI, and what happens to that override?

If the override doesn’t write back into the same system the AI is reading from — congratulations, you’ve built a feedback loop with the brakes cut. Every overridden recommendation that doesn’t update the source of truth is a re-run waiting to happen.

4. Who owns the data that flows out of the AI?

This is the question that kills more pilots than any other. The LIS vendor often considers data inside its system to be their data. The hospital believes it is theirs. The AI vendor would like it to be also theirs, for model improvement. Until that triangle is settled — usually in legal, not in engineering — your system can be unplugged at any moment.

What to design for, if you actually want this to ship

Three principles, in roughly the order they have saved my projects.

Make the integration the product, not the model. The model is interchangeable; the integration is not. The most defensible part of a clinical AI is its grip on the workflow it interrupts. Spend the engineering accordingly.

Plan for the LIS to lie to you. Assume the result you receive will sometimes be wrong, sometimes be stale, sometimes be in the wrong units, sometimes be a duplicate of one you saw 40 minutes ago. Build the layer that detects this before you build the layer that interprets it.

Earn write-back, do not assume it. Read access is cheap and political-cheap. Write access — putting your AI’s output back into the LIS where the clinician will see it next to the result — is the only thing that turns a recommendation engine into a clinical tool. It will take longer than your model. Start the conversation on day one.

The honest summary

Most clinical-AI startups think they are competing on model quality. They are not. They are competing on whether they can survive contact with a 20-year-old database written in Delphi by someone who retired in 2014.

If that doesn’t sound exciting, find a different domain.

If it does — welcome.

— C.