Billing agents that never open a clinical note.
Revenue cycle work is high volume and repetitive, which makes it a natural fit for agents. It also sits one table away from the most sensitive data a health system holds. Data.co Control lets RCM agents work claims while the policy engine keeps clinical documentation out of reach.
Payment is a permitted use. Unlimited reading is not.
HIPAA permits using PHI for payment activities, but the minimum necessary standard still applies: a workforce member or vendor working a claim should see what that claim requires. Revenue cycle teams already live by this through work queues and role-based screens. A general-purpose AI assistant connected to the EHR does not, because it reads whatever its service account can reach.
Outsourced billing adds a second layer. An RCM vendor working on your behalf is typically a business associate, and its agents should be distinct identities you can scope, audit, and switch off independently of your own staff. Data.co gives each agent a tagged identity, binds it to the same queue assignments a human biller holds, and evaluates every read against PHI labels before data reaches a model.
Billing data in. Clinical notes out.
The agent's identity is tagged rcm. Policies allow read access to billing and claims data for assigned accounts and deny every action on clinical notes, regardless of how the request is phrased.
From remit to appeal, with a human at the end.
- 1
Detect
The agent reads remittance data and flags denials by reason code for accounts in its assigned work queue.
- 2
Gather
It retrieves the claim, charges, payer rules, and the coded diagnosis and procedure fields it is allowed to see. Clinical narrative is excluded by policy.
- 3
Draft
A local model drafts the appeal letter from those sources, citing each field it relied on.
- 4
Escalate
If the appeal needs clinical justification, the agent routes a request to a credentialed staff member instead of reading the note itself.
- 5
Approve
Submission requires approval from a named biller. The decision and the approver are written to the audit log.
Scope expressed in a few lines.
Policies live in your Git repository and are tested in CI. These are illustrative starting points, not defaults you must accept.
id: pol_rcm_001
description: RCM agents may read billing data for assigned accounts
subject: { type: agent, tags: [rcm] }
resource: { dataset: [billing.charges, billing.claims, billing.remits] }
action: [read, search]
when:
resource.attr.assigned_queue: { equals: subject.attr.queue }
effect: allowIllustrative example · final API surface documented in /docs
Built for the way RCM teams already work.
Work queues as scope
Agent access follows the same queue and account assignments your billing team uses, so an agent sees what its human counterpart would.
Payer rules as reference data
Payer policies and contract terms are indexed as non-PHI reference material available to every RCM identity.
Outsourced RCM vendors
If a vendor operates the agents, their service accounts are separate identities with their own policies and audit trail.
Traceable drafts
Every drafted appeal links back to the claim fields and reference documents it used.
What RCM agents typically read.
Each source is labeled at ingest. The labels, not the source system, decide what an agent may see.
| Source | Examples | Typical agent access |
|---|---|---|
| Claims | 837 submissions, claim status (276/277) | Read for assigned queue |
| Remittances | 835 files, denial and adjustment codes | Read for assigned queue |
| Eligibility | 270/271 responses, coverage records | Read for assigned queue |
| Coded encounter data | Diagnosis and procedure codes, charges | Read, no narrative fields |
| Payer reference | Contracts, medical policies, fee schedules | Read for all RCM identities |
| Clinical documentation | Progress notes, operative reports | Denied; routed to credentialed staff |
What to ask before an agent touches a claim.
- Is each RCM agent, including a vendor's, a separate identity you can revoke?
- Does agent access follow your work-queue assignments automatically?
- Are narrative clinical fields excluded even when they sit in the same table as codes?
- Which actions can reach a clearinghouse or payer portal, and who approves them?
- Can you produce every read an agent made on a given account during a dispute?
- Do approvals expire, and what happens when nobody responds?
Questions buyers ask
Can an RCM agent be tricked into reading clinical notes?
Retrieval is filtered by the policy engine before results reach the model, so injected instructions in a document or prompt cannot widen access. A denied request returns the policy ID and reason and is logged.
What if an appeal genuinely needs clinical detail?
The agent can route a request to a credentialed person who has access. That person adds the necessary justification, which keeps clinical reading with humans who are authorized to do it.
Does the agent submit claims on its own?
Only if your policies allow it. Most teams start with drafting only and require a named approver for any submission to a clearinghouse or payer portal.
Does this replace our billing system or clearinghouse?
No. Data.co governs AI access to the systems you already run. It connects to billing and clearinghouse systems through connectors and MCP tools that the policy engine controls.
What happens to an approval nobody answers?
Each approval rule sets a timeout and an on-timeout outcome. In the example above, an unanswered submission request is denied after four hours, and the agent must start a new request. Approvals are single use.
Where should we start?
Denial triage and appeal drafting are common first workflows: high volume, a clear human approver, and no submission rights needed. Claim submission can be added after the audit trail has been reviewed.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.