An operator does the work, then proves it.
An operator is a scoped worker assigned to one workflow. It takes the input your staff take, acts in the systems you already run, stops where a person is required, and writes a record of every step. This page is the mechanism in full — how a run executes, where it runs, what it connects to, and where autonomy ends.
Four stages. The same four every time, whatever the workflow.
Denial appeals, referral intake, eligibility checks — the policy and the systems change, the shape of a run does not. Intake takes the work in at its source. Structure turns a document into fields with scores attached. Execute does the work in your systems of record. Audit writes down what happened, before and after it happens.
- Scope
- One operator, one workflow, one set of credentials. It cannot take an action its policy does not define.
- Stops
- Missing data, a score under the floor, an unexpected screen, or a readback that does not match all halt the run and raise an exception.
- Never
- Clinical judgment. Irreversible action without a named approval. Any path that moves PHI out of your environment.
Intake
Work arrives the way it already arrives: a fax in a queue, a document pulled from a portal, an HL7 message off your integration engine, an attachment in a shared inbox. The operator collects it at the source on a schedule or a trigger, timestamps it, and checks it against what it has already seen so the same packet is not worked twice.
The original is retained byte-for-byte and stays attached to every action taken from it. Nothing is retyped and nothing is thrown away, which is what makes the fifth step of a run defensible three months later.
Channels fax · portal pull · HL7 / FHIR · secure email · watched folder
Structure
The packet is read as a document, not as a string of text. The operator locates the fields this workflow needs — patient and encounter, coverage and plan, ordering provider, service codes, dates, denial reason — and resolves each one against the record rather than trusting what the page says.
Every field carries a score. Fields below the workflow's floor are flagged before anything is written, so a reviewer opens a specific field with its source page beside it instead of re-reading a twelve-page packet from the start. The output of this stage is a structured record with provenance, not a summary.
Output typed fields · per-field score · page and coordinates of the source
Execute
The operator does the work in the systems of record. Where a system exposes an API, it calls it with a scoped token and an idempotency key, so a retried step cannot post twice. Where no usable API exists, it drives the same screens a staff member uses, under a named service account your IAM team provisions and can revoke without calling us.
Which path applies to which system is decided once, at setup, and written into the workflow — not chosen per task at run time. Every write is read back and confirmed against the system. A mismatch halts the run and raises an exception; it does not retry blindly until something sticks.
Guarantees idempotent writes · least-privilege credentials · readback on every action
Audit
Each action is written twice: once as an intent, before it executes, and once as an outcome, after. An entry carries the identity that acted, the target system, the inputs it used, the score it acted on, the operator and policy versions in force, the result, and what changed.
Entries are append-only and chained to the one before them, so a record cannot be quietly revised after the fact. This is the stage that makes the second workflow a configuration change instead of a new security review — the evidence has the same shape every time.
Entry identity · action · target · inputs · score · versions · result
There is no Praxa cloud your records have to visit.
Praxa separates the plane that decides from the plane that acts. Workflow definitions, releases and routing live with us. Execution, documents, sessions and credentials live inside a boundary you control. Three deployment models sit on that split, and all three produce the same audit surface.
Read the security modelPlane 01 — yours
Execution
Where operators actually run. Documents, extracted fields and browser sessions stay in this plane.
Plane 02 — yours
Credentials
Service accounts and tokens live in your vault. A run requests a scoped credential; Praxa holds no standing access.
Plane 03 — Praxa
Control
Workflow definitions, model routing and release management. Configuration and metadata cross this line. Records do not.
- 01
Your cloud account
Operators run in a subscription you own, inside your network boundary. We ship signed images; your team owns the subnet, the egress rules and the keys.
- 02
Your data center
For environments that cannot egress, the same images run on hardware you already operate, with model calls routed through a gateway you approve.
- 03
Praxa-managed tenant
A dedicated single-tenant environment we would operate when infrastructure capacity is the constraint. PHI crosses into our environment in this model and nowhere else, so it is available only under an executed business associate agreement. We have not signed one yet, and we would not run this model before we had.
- 04
Who holds the credentials
You do, in all three models. Accounts are provisioned by your IAM team, scoped per workflow, and revocable without involving us.
- 05
Where models run
Model routing is configuration, not architecture. Each workflow declares the providers and regions it may use, and each step sends the minimum context it needs.
- 06
Versions and rollback
Operators, prompts and policies are versioned artifacts, not settings someone changed on a Tuesday. You pin a version, review the diff before it moves, and roll back to the exact configuration that produced any past result — which is also what makes a replay meaningful months later.
Connect through what your systems already expose.
No new interface, no migration, no request to open a system up. Each workflow declares the surfaces it may touch, and the operator uses the best one available: an interface when one exists, a credentialed session when one does not.
| Surface | Mechanism | What it carries | Control |
|---|---|---|---|
| System interfaces | REST · SOAP | Structured reads and writes against systems of record, scheduling and billing, where the vendor exposes an interface. | A scoped client or service token per workflow. Idempotency keys on every write. |
| HL7 v2 feeds | ADT · ORM · ORU · SIU | Admissions, orders, results and scheduling events, delivered by the integration engine your team already runs. | A standard interface on your engine. Inbound only, unless a workflow is specified otherwise in writing. |
| FHIR APIs | FHIR R4 | Resource-level reads, and writes where the system supports them, for patients, coverage, encounters and documents. | Registered as a client in your environment, holding only the resource scopes you grant. |
| Credentialed UI | Browser session | The systems with no usable interface: payer portals, licensing boards, clearinghouse screens, internal legacy tools. | A named service account you create, with a staff member's permissions and no more. Session steps recorded with the run. |
| Document channels | Fax · PDF · email · SFTP | Inbound faxes, scanned packets, portal downloads, secure attachments and watched folders. | The original is retained unaltered and linked to every action taken from it. |
| Outbound artifacts | Files · webhooks | Finished work products: appeal packets, worklists, reconciliation files, status events for your own systems. | Delivered to a location you nominate inside the boundary. Nothing is published outside it. |
Which systems an operator may reach, which screens it may open, and which credentials it may hold are scoped in writing per workflow before deployment, and reviewed with your security team rather than asserted on a website.
Autonomy is earned per workflow, not granted per product.
Every field an operator extracts and every action it proposes carries a score. Each workflow sets two lines on that scale: a floor, below which nothing proceeds without a person, and an autonomy line, above which the operator acts on its own.
Between the lines, the operator acts and the work is sampled for review afterwards. Below the floor, the item goes to a reviewer with the source document, the specific field in question, and what the operator would have done — not a queue of packets to work from scratch.
Both lines start conservative and move only on evidence: accuracy measured against a labelled set for that workflow, then live sampling once it is running. Every change is a versioned, reversible configuration change with a name attached to it.
Exceptions land where your team already works — a worklist, a queue in the system of record, a shared inbox — each one linked back to the run that raised it. Reviewer decisions are recorded against the field and the operator version that produced it, which is how the next threshold change gets argued from data instead of instinct.
- Read or reference
- Autonomous once accuracy on that workflow is established.
- Reversible write
- Autonomous above the line, and reversible from the log if it was wrong.
- Irreversible action
- A submission, a release, anything a person cannot take back: named approval every time, until a reviewed accuracy history exists for it.
If it is not in the log, it did not happen.
Automation is easy to buy and hard to defend. The question a compliance officer asks is not whether the work got done — it is who did it, on what basis, and can you show me.
A completed run answers that without anyone reconstructing it. Every entry names the identity that acted, the system it touched, the inputs it used, the score it acted on, and the operator and policy versions in force at that moment. A run from March replays step by step in September against the same document and the same versions that produced it.
That is also why the second workflow is easier than the first. The review you pass once is the review you keep passing, because the evidence arrives in the same shape every time.
- Captured
- Identity, action, target, inputs, score, versions, result, and the source document behind all of it.
- Exportable
- Streamed to your SIEM, loaded into your warehouse, or handed over as a signed file set for an internal audit, an external one, or a payer dispute.
- Yours
- Retention windows, access scopes and who may read the log are set by you and enforced inside your environment.
- 14:02:07OPR-4Ingest source document · DOC#8812Stored
- 14:02:09OPR-4Extract fields · policy v14 · operator v311 flagged
- 14:03:41J.REYESApprove corrected field · auth referenceSigned
- 14:03:44OPR-4Write to system of record · readback okConfirmed
- Each entry is chained to the one before it. A chain that does not verify is itself an alert.
Bring a workflow. We will walk the trace.
Pick the queue that costs you the most people. We will show you an operator executing it end to end on your process, and then show you the record it leaves behind.
Request a demo