Healthcare AI Execution Governance
Bound what a clinical or RCM agent can change before it writes.
Prior-authorization and revenue-cycle agents create consequential side effects. Execution governance evaluates those actions before they run, denies unauthorized modifications, and can produce evidence you can verify independently.
Answers the question: “How do we govern healthcare AI agent actions so unauthorized modifications never execute?”
Why healthcare agents need an execution boundary
A model can propose a prior-auth change that looks plausible. The production question is whether that exact modification — fields, codes, patient context — is allowed to execute now.
An agent widens a prior-auth request beyond the approved envelope and the write succeeds.
Prompt instructions say "don't change X" while the tool path still accepts the mutation.
PHI-bearing payloads leave the environment on an ungoverned tool call (separate problem from network egress products).
Post-hoc audit shows the unauthorized change after it already hit the payer or EHR interface.
Approvals are informal chat messages unbound to the exact action bytes.
Bring one consequential healthcare action
Name the mutation you must bound or deny — prior-auth field change, claim edit, disclosure — and the effect-producing route.
Reference proof surface
What we can show publicly today comes from the OSS RCM reference — not from a certified production PHI deployment on this page.
Honest scope
This page describes an open-source reference architecture (@strixgov/rcm-reference): the same prior-auth agent task run ungoverned vs governed across failure modes on an X12 278 surface with synthetic patients only.
It is not a HIPAA certification, FedRAMP authorization, clinical product claim, or guarantee about your production PHI paths.
What execution governance contributes
Same Strix kernel pattern as other domains: evaluate the proposed action, allow within bounds, deny unauthorized modifications, intercept when a human must decide, and record evidence.
| Capability | How Strix delivers it |
|---|---|
| Bounded modification | Encode which fields and ranges an agent may change for a prior-auth or RCM task. |
| Unauthorized modification denied | Fail closed when the proposed write leaves the allowed envelope — before the side effect. |
| Human intercept | Hold high-risk changes for a person when policy requires it. |
| Evidence | Produce decision records that can be verified independently when signing is enabled. |
| Synthetic reference | @strixgov/rcm-reference runs governed vs ungoverned failure modes on synthetic patients / X12 278. |
| Non-claims | Not a HIPAA cert, not clinical decision support, not a guarantee about your PHI egress paths. |
Proof, not promises
Every claim Strix makes is backed by an artifact you can independently verify.
RCM reference package
Open-source governed vs ungoverned prior-auth reference on synthetic data.
@strixgov/rcm-referenceIndependent verifier
Same verify primitive used across Strix evidence.
npx @strixgov/verifier@latest 5686Related boundary
For MCP tool routes carrying healthcare side effects, see MCP action governance.
/mcp-action-governanceFrequently asked questions
Is Strix HIPAA certified because of this page?+
No. This page documents a synthetic reference architecture. Certification and PHI program controls are separate and customer-specific.
Does this stop PHI from reaching an external model?+
That is primarily an egress / redaction / data-path problem. Strix governs whether a consequential tool action executes. Do not treat this page as an egress-control product claim.
Where is the runnable proof?+
In @strixgov/rcm-reference on npm / GitHub Strixgov/strix — dependency-free ESM with node --test.
How does this relate to prior-auth clinical intelligence products?+
Clinical necessity determination (e.g. specialized prior-auth platforms) is a different layer. Strix governs whether the agent's resulting action is allowed to execute and can sign evidence of that decision.
Other healthcare paths
Same execution boundary, different room. Each starts from one consequential action and states what Strix can — and cannot — prove about it.
For RCM & automation vendors
You sell the automation. Hand a health-system or payer buyer evidence they verify without trusting you.
Open →Denials & ADR response
Appeals, additional-documentation requests, and the minimum-necessary boundary on what leaves for a payer.
Open →Prior authorization, end to end
The interactive walkthrough: the same prior-auth agent run ungoverned and governed across five failure modes.
Open →For providers & health systems
Your agent touches the payer portal and the chart. Which of those writes is allowed to execute, and on whose authority.
Open →For payers
Automated determinations are consequential actions. Bound them and keep a record a regulator can check.
Open →