Written for the person
who has to approve it.
Hospital IT, a security reviewer, an RCM partner's architect. The question is not what the platform is called — it is how data gets in, what happens to it, who can reach it, and which parts do not exist yet. This page answers that in order.
One deployable, bounded modules
Revitics is a modular monolith: ingestion, reconciliation, contract terms, pricing, evidence, recovery, identity and reporting are separate modules with explicit interfaces, deployed as one service against one relational database.
That is a deliberate trade, and it costs something. A single deployable cannot scale one module independently of the others, and a bad release affects everything at once. What it buys is the property this product actually needs: a claim, its remittance, the contract term that priced it and the evidence that proves it are read inside one transaction, from one source of truth, with referential integrity the database enforces. Distributed across services, that same read becomes four network calls that can each return a different version of the truth — and the number in the letter is the thing that must not be wrong.
What happens to a file, in order
Every stage is separately auditable and separately re-runnable. Nothing in this path silently discards a record: an item that cannot be matched or cannot be priced leaves the happy path into a queue that names the specific reason and the options that would resolve it.
Receive
Files arrive at a per-connection endpoint with a scoped key, or by CSV upload with a confirmed column mapping. The transfer is recorded before parsing begins, so a file that fails to parse is still a file the system knows it received. Anything large enough to block a request is handed to a background worker rather than parsed inline.
Parse
X12 is read segment by segment — CLP, SVC, CAS,
PLB, BHT04, CLM05-3 — and structural
acknowledgements are interpreted rather than filed. A malformed interchange fails loudly
with the segment and position that broke it, because a parser that guesses produces a
financial figure nobody can defend.
Normalize
Everything becomes one claim model. This is the line the rest of the system depends on: no source-format or vendor-specific logic exists downstream of it, which is why adding a connector never changes the financial engine.
Reconcile
Remittances are matched to claims and to individual service lines. Where a match is ambiguous the record is queued with the reason it could not be matched, the candidates considered, and the specific action that would resolve it — a file sitting in a queue with no explanation is a file nobody will ever work.
Price
Expected reimbursement is computed per line from human-verified contract terms. A line the engine cannot price is reported as not computable and does not suppress the lines it can price — an early version let a single unpriceable line erase genuine findings on the same claim.
Package
An approved appeal is serialised with its exhibits into a bundle that is then frozen and hashed. Approval and transmission read the same bytes, so "what was approved" and "what was sent" are the same question with one answer.
Attribute
A later remittance carrying recovery — or a takeback reversing one — is tied back to the finding and the appeal that produced it. Prioritisation learns only from concluded outcomes, and reports insufficient history rather than inventing a win rate.
The claim graph
Most of the correctness in this system is a modelling decision rather than an algorithm. Four of them do most of the work.
A finding references a claim version, an adjustment and a verified term rather than copying their values. Copying is how a figure quietly stops matching the record it came from once a later file arrives.
A correction is history
A corrected 837 becomes a new version of an existing claim, linked to the one it replaced. Pricing reads the version that was actually adjudicated, so the engine never argues a figure the provider has already superseded and a resubmission is never counted a second time as new leakage.
Two states, one of them inert
Every extracted contract term starts as a candidate carrying a pointer to the clause it came from. A candidate cannot price a claim and cannot be quoted to a payer. Only a person moves it to verified. This is the single most important boundary in the system, because it is the one that decides what may appear in a letter.
Takebacks stay separate
A provider-level adjustment is recorded alongside the payment it offsets rather than mutating it. A retransmitted 835 therefore cannot double a takeback, and recovery attribution cannot be debited twice for one event — both of which happened in earlier versions and were fixed here, in the model, not in a report.
Confidence is not one number
A finding stores the basis of its recoverability separately from the confidence in the financial calculation. Blending them produced a screen that claimed 97% confidence in a figure that rested on a 70% assumption — so they are stored, and shown, apart.
What AI may touch, and what it may not
This boundary is architectural rather than a policy someone is trusted to follow. The financial core takes no model client, so there is no call site at which a model could influence a dollar figure even if someone wanted it to.
May cross
- Reading a contract and proposing candidate terms for a person to verify
- Classifying a denial narrative into the payer's own coded reasons
- Summarising a claim history for a human reviewer
- Drafting appeal language a reviewer then edits and approves
- Suggesting which documents a stated denial reason usually requires
May not cross
- Calculating expected reimbursement, variance or any amount
- Scoring, ranking or prioritising a finding
- Deciding whether a finding is recoverable
- Marking a contract term verified
- Approving, altering or sending anything to a payer
Who can see whose rows
Tenancy is resolved from the authenticated session at the edge and applied in the data layer, not assembled by each handler. A query that forgets its tenant filter is a query that does not compile into a valid scope, rather than one that quietly returns everything.
A provider organization
Sees its own claims, contracts, findings and packages. Roles inside it differ — a reviewer, an approver and an analyst do not see the same actions — but the outer boundary is the organization.
An RCM firm above several customers
Sees portfolio-level totals across the clients that have granted it access, under its own brand. The hierarchy grants aggregates. It does not grant row-level access to any client's claims, and that boundary is covered by tests rather than asserted in a questionnaire.
Revitics itself
A tenant like any other, which is what keeps commercial and sales material out of customer organizations. Training visibility is scoped by credential, so what a person can open is decided by what they are — not by which link they were sent.
EHR-agnostic by construction
The claim to be EHR-agnostic is only meaningful if it is structural. Here it is: normalization is the boundary, and nothing downstream of it knows which system a record came from. Adding a source is a connector; it is not a change to the financial model.
Implemented
X12 837P, 837I, 835, 277/277CA and 999 parsing and reconciliation. 276 claim-status request generation. CSV with a confirmed column mapping. Secure file delivery to a per-connection endpoint with a scoped key.
Framework in place
FHIR, HL7v2, SFTP and vendor APIs sit behind a single connector interface. The interface exists and the X12 and CSV paths are built on it; the remaining adapters are not.
Not claimed
No production Epic, Oracle Health or Cerner integration exists today. This page will not say otherwise until one is live and verified with the customer it runs for.
How it is changed without breaking
Versioned migrations
Every schema change is a migration, and a test fails the build if the models and the migrations have drifted apart — the failure mode where code and database disagree only in production.
Tests as the contract
The financial engine, the X12 parsers and the tenant boundary are covered by automated tests. A defect gets the test that proves it before it gets the fix.
Background work
Imports past a size threshold run asynchronously so a large file cannot hold a request open or time out halfway through a parse.
Audit as a record
Authentication, privileged actions, exports and financial decisions are written as they happen, so the trail is a record rather than something reconstructed from logs afterwards.
What is not built yet
An architecture page that lists only what exists is the same as a security page that lists only strengths. These are the known gaps, stated before you have to find them.
No published connector SDK
The internal connector interface exists and is what the X12 and CSV paths are built on. There is no documented, versioned SDK a third party could write an adapter against without us. That is the largest remaining engineering gap.
No production EHR integration
The adapter framework is real; a live, verified integration with a major EHR in production is not. Until one exists a pilot runs on files, which is a deliberate design choice and also currently the only option.
People Platform partly specified
The public careers experience is live. Applicant tracking, offers, onboarding and employee self-service are specified against this same architecture and not yet built. See its product page, which marks each module.
No third-party attestation
No SOC 2 report and no independent penetration test exist today. Nothing on this site describes either as complete, and security and trust says so in the same words.
Delivered as software, not as an outsourcing contract
Your team operates it
You keep control of your revenue cycle. There is no requirement to hand it over.
Or a certified partner does
An RCM firm runs the platform for its clients under its own brand, seeing portfolio totals and never a client's claims.
Or both
Your staff and a partner working the same queue, with role-based access and an audit trail that says who did what.