AntecedentHealth
Healthcare records intelligence
Talk to us
Now onboarding customers

Two questions.
One records layer.

Healthcare already wrote everything down. The chart note, the medication administered, the procedure performed, the code submitted, the payer's answer. The record exists — what's missing is a governed way to read it. We build that layer, and we point it at two deliberately separate questions.

Every finding cites the document it came from.

Retrieval-groundedFindings are anchored to a source document and the passage is shown, not summarized
De-identified firstPHI is tokenized in our middle layer before any model sees a record
Service-date scopedRules are versioned and applied as of the date of service, not the date of the run
Two firewalled divisionsSeparate corpora, separate access, separate customers. By design
The premise

The hard part was never the model.

An enterprise AI system in a regulated setting has three layers. The language model is the least differentiated of them — everyone can rent the same one. The data underneath is the customer's, and it is theirs alone. What determines whether the system is trustworthy is the layer in the middle.

Governance and escalation

What the system is permitted to conclude on its own, what it must route to a human, and what happens when it is uncertain. Written down as rules, not left to a prompt.

PHI handling

Records are de-identified and tokenized before inference. The token preserves the patient's longitudinal journey without carrying their identity. Access is logged; authentication is multi-factor.

Provenance

A finding that cannot be traced to a source document is not a finding. Every output carries the citation and the version of the rule set that produced it.

Why this matters commercially, not just technically

A coding finding you cannot defend to a payer is worthless. An outcome signal you cannot defend to a manufacturer's medical affairs team, or to a reviewer, is worse than worthless. In both of our divisions the deliverable is not an answer — it is an answer with its evidence attached.

Two divisions

Deliberately separate. Different buyers, different data, different risk.

These two programs share an ingest and extraction layer and nothing else. They are not two features of one product, and we do not sell them as a bundle. A customer of one need never encounter the other.

Division One

Revenue Integrity

Optimizing insurance billing workflow against the treatment that was actually provided.

Who it serves

Medical billing companies, physician groups, and health systems — the people responsible for getting a correct claim paid the first time.

  • Procedure-to-diagnosis coding consistency at the service-line level
  • Denial risk scored before submission, with the reason cited
  • Rules applied as of the date of service, not the date of the run
  • Documentation-to-code support: does the note carry the code?
Revenue Integrity in detail →
Division Two

Clinical Evidence

Analyzing treatment data — procedures, medications, side effects, outcomes — to inform how patients are treated and diagnosed, and to feed real-world usage signal back to manufacturers.

Who it serves

Health systems and quality teams, clinical research organizations, and pharmaceutical medical affairs and post-market surveillance groups.

  • Longitudinal patient view assembled across encounters
  • Treatment-to-outcome association surfaced with its source passages
  • Adverse-event and side-effect signal from records already collected
  • De-identified, aggregated real-world usage reporting for manufacturers
Clinical Evidence in detail →
On the separation. The two divisions run on separate corpora with separate access control. Billing-side data does not inform manufacturer reporting, and clinical analysis is never conditioned on reimbursement outcome. That boundary is an architectural commitment, not a policy statement — it is the reason the two are built as separate programs rather than one product with two dashboards.
What they share

One insight built both of these.

Everything that goes wrong downstream in a claim was already decided upstream in the record. The code is derived from what was documented; the denial is derived from the code. So the useful place to stand is not at the claim — it is at the note.

1 · The recordChart notes, encounter data, medication and procedure detail — structured and unstructured
2 · ExtractionNormalize, de-identify, tokenize. The shared layer both divisions stand on
3 · RetrievalGround the question in a versioned corpus of authoritative source documents
4 · ReasoningModel inference under explicit governance and escalation rules
5 · FindingAn answer, the citation behind it, and the rule version that produced it

Steps 1 and 2 are common to both divisions. Steps 3 through 5 diverge completely: the billing corpus and the clinical corpus have nothing to do with each other.

Where this actually stands

Built, live, and ready for customers.

We would rather be believed than impressive. The platform is a working build, one industry design partner is engaged and validating output against real workflow, and we are actively onboarding new customers now.

Today

Working software: ingest, de-identification, retrieval-grounded per-claim analysis with cited findings, and an authenticated interface. One design partner from the medical billing industry is reviewing output against real-world workflow, and we are onboarding additional customers.

In build

Service-date-scoped rule versioning. Payer-specific rule sourcing. Documentation-to-code derivation from the note. Denial-history feedback so the system learns from actual adjudication outcomes.

Roadmap

The Clinical Evidence division: longitudinal patient assembly, outcome and side-effect signal, and de-identified aggregate reporting for manufacturers. Design work is underway; this division is not yet in production.

What we are not claiming

  • No completed pilot yet, and no published accuracy or denial-reduction figure
  • Not a medical device, not FDA-cleared, and not clinically validated
  • Not a diagnostic, and not a substitute for clinical judgment or a certified coder's review
  • No claim to discover biomarkers, predict drug response, or do any laboratory or pre-clinical science
  • Nothing here replaces a billing system, a clearinghouse, or an EHR — it is a layer above records those systems already hold
Why we built this

Built by operators who run regulated data pipelines for a living.

Antecedent Health is built on Amazon Web Services and runs on Amazon Bedrock. We built it because the engineering underneath it is the engineering healthcare organizations keep needing: PHI boundaries, retrieval you can audit, and governance that holds up when someone asks how the system reached a conclusion.