What We Build: AI and Automation Products | CercaLabs

Engineering evidence

The software we run ourselves

Two production products with patients on the other end. This is the page to read if you want to know whether we can build the thing, rather than describe it.

Both are here as proof of engineering practice. They run their own sites and their own roadmaps.

Clinical records de-identified before a language model ever sees them CLINICAL RECORD De-ID Safe Harbor WHAT THE MODEL SEES The eighteen identifiers never leave the boundary.

Being straight about it

Why This Page Exists

Our published case studies are automation and language-processing work from 2018 onward. Our current-generation model work is in our own products. So this page carries the evidence for anything we say about AI.

We would rather be explicit about that than let a reader assume a client engagement behind every capability claim. If a named enterprise AI reference is a hard requirement for you, say so early and we will tell you honestly where we stand.

Product one

Drug Search

A patient-facing tool that finds prescription medications compatible with a person’s excipient allergies, by matching their sensitivities against public drug labeling data. It turns a manual ingredient-list review into a straight answer.

The engineering problem is data integration and normalization at scale. Authoritative labeling data is public, but it is structured for regulators rather than for a patient trying to find out whether a specific generic contains a specific dye. Reconciling excipient nomenclature against manufacturer labeling across thousands of formulations is the hard part, and it is the same class of problem as reconciling payor policy language against a claim.

Visit Drug Search ↗
A hand sorting tablets into a weekly pill organizer beside a blister pack
For a patient with excipient allergies, every new prescription is an ingredient audit.

Product two

BookCover For Patients

A production application built on a commercial large language model API, with a de-identification pipeline in front of it. It is our only current-generation model system with clinical data behind it, which makes it the load-bearing evidence for the way we handle AI and patient data.

BookCover runs its own site and its own marketing. It is here as proof of what we can build.

De-identification that preserves meaning

Clinical text can be stripped of identifiers before it reaches a model without losing the clinical sense the model needs. Getting that balance wrong in either direction is the usual failure.

The mapping stays inside the boundary

Re-identification happens on our side of the line, never the model provider’s. That is the design decision a security reviewer actually cares about.

Logging and evaluation built in

Request logging and output evaluation were part of the first version rather than bolted on after someone asked for an audit trail.

Visit BookCover ↗

Built for ourselves first

How Each Capability Maps To A Service

Every capability below is something we built for ourselves first and now implement for clients. That is the whole argument of this page.

What we built Where it came from What we offer clients
De-identification before model inference BookCover Safe handling of patient data in AI workflows
Extracting structure from unstructured clinical documents BookCover Document-heavy workflows: appeals packets, payer correspondence, requisitions
Normalizing authoritative regulatory data into usable answers Drug Search Payor policy and denial-reason interpretation
Evaluation harnesses for model output Both products Reliability measurement and shadow-mode deployment before anything goes live
Request logging and audit trails on model calls BookCover Governance and audit posture

Questions we get

Questions About This Page

Can we buy these products?

No. Both are patient-facing products with their own sites and their own roadmaps. They are here as engineering evidence of what we can build for clients.

Why does it matter that you build your own?

It is the difference between having implemented a pattern and having operated one. Every hard decision in a production model system: what to do when the model is uncertain, how to de-identify without destroying clinical meaning, what to log. We have had to make for real, with users on the other end.

What is the actual stack?

A commercial language model API under enterprise terms, a custom de-identification pipeline in front of it, authoritative public data sources, and evaluation harnesses rather than hand-tuning. Orchestration is our own code, kept deliberately debuggable. We will name every component in a security review.

Does this mean every engagement uses AI?

No, and most do not. Plenty of the work that delivers the largest return is rules-based automation with no model anywhere near it. Where AI fits is a narrower question than the market suggests.

Next step

Ask Us The Hard Version

If you have an engineering or security question these pages do not answer, bring it to the teardown. We would rather have that conversation early than discover the gap at contract stage.

Book a teardown