Nothing has to change
before this works.
It runs on the systems you have today
The first question a payer asks is what has to change before any of this works. The answer is nothing. The connectors speak the interfaces the plan already exposes, and the parser reads what the mainframe emits today — below, the same synthetic request arrives twice, once as X12 278 and once as FHIR, and lands as one canonical record both times.
It runs under rules you set
A health plan cannot place an unconstrained agent near a coverage decision, and legal is right to refuse. Governance is not a module bolted alongside the AI — it is the condition of the AI existing at all, so it lives in the substrate every workflow is built on. Below, three model calls cross the gate: one passes, one is refused fail-closed, and the adverse one holds until a licensed physician signs.
It leaves a record that outlives the engagement
Reconstructing who decided what, on which policy version, on what evidence — retroactively, under subpoena — is ruinous. Building it as the work happens is a line item. Below, the record assembles: each entry seals to the previous hash, the same date answers differently on the validAt and knownAt axes, and the chain re-verifies offline from the record and a public key alone.
Your workflow is the only thing left to build.
The substrate does not depend on what you decide to run on it — identity, the PHI gate, the human gate and the evidence spine are the same for every workflow, which is why they can arrive complete before you have told us what you want. Week one goes to the one thing that cannot exist without you: your workflow, on your systems.
This is what arrives.
The workflow-agnostic half of a deployment is already built, already versioned, and already speaks the transaction sets a plan runs on. It is the half that does not depend on what you decide to run, which is why it can arrive before the conversation does.
- versioned capabilities
- 19versioned capabilities
- reachable by MCP, CLI or API
- 17reachable by MCP, CLI or API
- standards and protocols spoken
- 21standards and protocols spoken
CARC · CMS-0057-F · CPT · Da Vinci CRD · Da Vinci DTR · Da Vinci PAS · FHIR R4 · MCP · MUE · NCCI · NCQA UM · NPPES · RARC · US Core · X12 270 · X12 271 · X12 275 · X12 278 · X12 834 · X12 835 · X12 837
MCP servers
1Typed, PHI-gated tool surfaces an agent binds to- Claims operations MCP serverv2.0.0MCP
Claim read, authorization read, remittance read, evidence write. Every tool risk-classified; a high-risk write routes to an approval gate rather than executing.
MCPAPI
Command line
1What an engineer runs on day one- hnx command linev1.9.0
Connect a source, scaffold a workflow, run an evaluation, seal evidence, promote a version.
CLI
APIs
1HTTP surfaces a system calls- Operations graph APIv2.3.0
Permission-filtered read across the operations graph — objective to workflow to run to evidence — with provenance on every edge.
API
Connectors
5The interfaces a plan already exposes- X12 278 authorization connectorv3.1.4X12 278 · X12 275
Request and response for services review, with deterministic parse, envelope validation, and reconciliation when transport is ambiguous.
CLIAPI - X12 835 remittance connectorv3.0.9X12 835 · X12 837
Remittance ingest with CARC and RARC mapping, contract-rate comparison, and variance emission.
CLIAPI - X12 834 enrollment connectorv2.4.1X12 834
Enrollment and maintenance ingest with discrepancy detection against the eligibility system of record.
CLI - Da Vinci PAS / CRD / DTRv2.2.0Da Vinci PAS · Da Vinci CRD · Da Vinci DTR · FHIR R4
FHIR prior-authorization support: coverage requirements discovery, documentation templates, and submission.
API - FHIR R4 gatewayv3.3.2FHIR R4 · US Core
Conformance-checked read surface across Patient, Coverage, Claim, Practitioner and Organization.
API
Agents
4Skilled workers on the governed harness- Prior authorization agentv5.0.1CMS-0057-F
Assembles the clinical packet, checks criteria, drafts the determination rationale. It never issues an adverse determination — that stops at a licensed reviewer.
MCPAPI - Claims denial management agentv4.1.3X12 835 · X12 837
Classifies the denial reason, gathers the supporting record, drafts the appeal. It files nothing without approval.
MCPAPI - Coding integrity agentv2.6.0CPT · NCCI · MUE
Reviews code selection against documentation, flags MUE and NCCI conflicts, proposes corrections for a coder to accept or reject.
MCP - Eligibility and enrollment agentv1.4.2X12 834 · X12 270 · X12 271
Resolves disagreements between an enrollment feed and the eligibility system of record, and proposes the correction with its source authority attached.
MCP
Workflows
3End-to-end, with the human gates named- Prior authorization — intake to determinationv4.2.0X12 278 · Da Vinci PAS · CMS-0057-F
Intake, evidence assembly, clinical criteria check, a human gate on every adverse determination, payer submission, and authoritative readback.
CLIAPI - Payment variance and recoveryv3.4.1X12 835
Expected-versus-paid comparison against contract rates, variance case creation, a recovery work queue, and finance-approved readings.
CLI - Provider roster reconciliationv2.1.0FHIR R4 · NPPES
Reconciles a roster against source authority and proposes directory corrections with provenance, routed to the function that owns the field.
CLI
Control profiles
1The gates a regulated workflow must satisfy- Utilization management control profilev3.0.4CMS-0057-F · NCQA UM
Licensed reviewer on every adverse determination, the turnaround clock, notice content, and appeal rights.
Datasets
1Reference data the workflows resolve against- CARC / RARC reason mappingv2026.08CARC · RARC
Denial reason codes mapped to recoverability, the owning function, and the evidence each appeal requires.
Evaluation sets
2The bar a change must clear before promotion- UM determination evaluation setv1.7.0
Labelled synthetic determinations with expected outcomes and rationale quality bars — the gate a UM agent clears before promotion.
CLI - Coding accuracy evaluation setv1.2.0CPT · NCCI
Labelled encounters with the correct code selection and the documentation that justifies it.
CLI
A dashboard is not a control.
Observability makes behavior visible. A control plane makes policy operational. The question a plan is actually asking is not whether an agent can do the work — it is what happens at the moment one of them tries to do something it should never have been able to do. Below, that moment, four times.
A check performed by the thing being checked is not a check. The verifier is either a deterministic tool or a different model lineage, and the disposition belongs to a named human in a named role — the same separation of duties an auditor already expects everywhere else in the plan.
Deterministic checks and model-based checks are not alternatives. Schema, policy, access and lineage are decided by code, because those answers must be the same every time. Intent and business logic need judgement. A control plane that runs only one of the two is missing the half it finds inconvenient.
The model should be the easiest thing to replace.
A foundation model is a fine place to start and a poor place to be structurally dependent. We deploy either way — but where the data is regulated, the durable answer is a model you host, on capacity you control, that can be tuned on data which never leaves the building.
- The model is a component
- Not the architecture. A workflow is built against a typed interface, so the model underneath is replaceable when a better one arrives — and replacing it is a configuration change, not a rebuild. Anything that makes a specific vendor's model structural has sold you a dependency and called it a platform.
- In your environment
- Hosted in your cloud tenancy or on your own hardware. The deployment is single-tenant by design; there is no shared data plane behind it and no licence check that can switch it off.
- Trained on your data, in your environment
- Fine-tuning and small-model work run where the data already lives, so it is never copied out to be trained on. That is the whole reason to do it this way.
- Cost you can predict
- Owned capacity prices like infrastructure rather than like a meter. A per-token bill is a variable you cannot forecast and cannot cap, which is a budgeting problem long before it is an engineering one.
The engineers who set the boundary have sat on the other side of it — running security and compliance functions, and being audited rather than only reading the report afterwards. It is the difference between a control that satisfies a questionnaire and one that holds when somebody tests it.
No modernization required.
The governed layer attaches above the systems you already run and reads and writes through typed tools. Nothing below is replaced, re-hosted or migrated.
- No data migration. Your systems keep their records.
- No replatform. Core admin remains the system of record.
- No rip-and-replace of the UM platform.
- No PHI moved out of your environment to make any of it work.
What ‘connects to your systems’ actually means
A connector described without its limit has not been built yet.
X12 EDI, behind your clearinghouse
837, 835, 270 and 271, 278 — consumed and produced on the transport you already run.
We do not become your clearinghouse. We sit behind the one you have.
FHIR R4 and the CMS-0057-F APIs
Coverage requirements discovery, documentation templates and the prior-auth API, where a plan has stood them up.
Where they are not stood up yet, that is week-one work — not a prerequisite for starting.
HL7v2 feeds
ADT and results consumed in the dialect the sender already emits.
The sender is not asked to change. Dialect handling is ours, per feed.
SFTP batch and flat files
The real interface to most core platforms. Landing zone, schema pinned per file, checksum per drop, replay on failure.
A nightly file does not become a real-time feed because an agent reads it.
Read replicas and change data capture cover reporting; screen-level automation is the last resort, and is still a typed tool with a recorded before and after. Every attachment runs read-only in shadow first, and promotion is signed by the plan.
It does not stop at prior auth.
Because those three layers land once, the second workflow costs a fraction of the first — the connectors, the gate, the audit chain and the human-review machinery are already in place. Prior auth, claims & appeals and the voice channel exist as prebuilt accelerators in a catalog: proof of how fast the framework builds, never the boundary of what it builds. You tell us what you want next, and it runs on the same substrate without re-entering procurement.
Deeper: the first workflow · how a past decision is rebuilt · why it compounds