NCCI edits0 errors · 0 warnings
Every pair of procedure codes on the claim is run against the NCCI procedure-to-procedure edits. This one passed with nothing to fix.
V3ra Platform · Sync Running today
Sync
Every line of the claim, checked before it leaves.
Runs on VAS, the system underneath every V3ra product→What Sync does
The note says what happened. The claim says what gets paid. Sync keeps the two in step.
It reads the encounter while it is still open, drafts the coding, and checks every line before the claim leaves: the edits, the level, the work left unbilled, the revenue and a clean-claim score. Where it cannot be sure, it says so on the screen.
5checks on every claim, in order
32.0 sthe whole run on this encounter, as the platform timed it
0 · 0NCCI errors and warnings on this claim
99285the level, argued two of three
The audit pipeline
Five checks, in order, on every claim.
Each runs on the claim as it was drafted, and each leaves its result on the screen for the person who confirms it.
- NCCI edits0 errors · 0 warnings
- E/M level99285 · two of three
- UndercodingNone found
- Revenue1.80× assumed
- Claim score100 of 100
32.0 seconds for all five, as the platform timed it.
E/M level99285 · two of three
The level is rebuilt from the note, not copied from the claim: medical decision making, on the two-of-three rule.
UndercodingNone found
The note is read for work it documents that the claim does not carry. Nothing was left out of this one.
Revenue1.80× assumed
Each line is priced against the fee schedule. The payer was never recorded, so it applies the 1.80× Medicare default and says so beside the figure.
1.80×MedicarePayer unknown · assumed
Claim score100 of 100
Clean on every check it runs, and ready for a person to confirm. Nothing leaves until someone does.
100of 100Claim ready
The level, argued
Two of three hold it up.
Medical decision making has three elements: the problems addressed, the data reviewed and analysed, and the risk of what was decided. The level is the one two of them reach. Here problems and risk reach high; data comes out minimal and stays on the page anyway.
ProblemsHighFour diagnoses assessed, the most severe high
DataMinimalNothing counted from tests, records or discussion
RiskHighThe highest tier of risk, triggered
Calculated99285MDM high · two of three
In the emergency department the level comes from decision making alone. Time does not count.
It says what it does not know
Two figures, and the gap between them.
The payer was never recorded, so Sync cannot know the rate this claim will be paid at. It prices the visit from the CMS schedule, applies the 1.80× default for an unknown payer, and keeps that assumption on the screen beside the figure, rather than passing it off as the rate.
99285 at Medicare, CY2026 schedule$171.35
The same visit at the 1.80× default$308.43
× 1.80 · assumed for an unknown payer, and shown99285 · 5.13 RVU × $33.4009 = $171.35 · × 1.80 = $308.43From the platform’s fee schedule, CY2026
“No original hospital coding was available for comparison. Uplift cannot be calculated without a baseline.”
The billing summary, in the platform’s own words
What it should pay
Priced line by line, from the schedule and your contracts.
Each line is priced from the CMS Physician Fee Schedule: its relative value units, adjusted for the locality, times the conversion factor and the payer’s multiplier. Where a payer’s contract has been loaded and promoted, its terms price the line.
Workthe physician’s time and skill
+Practice expensestaff, space and supplies
+Malpracticethe cover the service carries
×GPCIeach part adjusted for the locality
×Conversion factordollars per relative value unit
×Payerthe multiplier, or the contract
=The lineits price on this claim
Medicare from the CMS schedule. The payer columns are default multipliers until that payer’s contract is loaded.
A payer’s own contract, from upload to price
- UploadPDF, Word or text, many contracts at once
- ReadTheir terms drawn out into a review queue
- ReviewedA person edits each before it counts
- PromotedThe next claim prices on it
Written once
Drafted at the bedside, carried into the claim.
The codes drafted while the encounter was open arrive in the claim marked as drafts. A coder confirms, removes or adds to them there, rather than typing them again.
Clinical dashboard during the encounter
96374IV push, initialI40.9Acute myocarditisI30.9Acute pericarditisI26.99Pulmonary embolism
Drafted while the patient was still in the room.
Claim codesFrom the analysis · editable
99285ED visit, high complexity96374IV push, initialI40.9Acute myocarditisI30.9Acute pericarditisI26.99Pulmonary embolism
Confirm, remove or add. Nothing is typed twice.
What leaves the building
One export, every piece in it named.
The claim leaves as a package: the encounter, its summary, the scrub, the claim itself and a manifest that fingerprints every file. The billing mode, compliant or maximum defensible, comes from the encounter, and export never raises a code on its own.
JSONfhir-bundle.jsonThe encounter as a FHIR R4 bundle, validator-ready
PDFencounter-summary.pdfThe confirmed fields, with the payer attestation when asked for
PDFscrub-report.pdfThe scrub, as a checklist, with its JSON beside it
EDIclaim.837.ediThe X12 837 claim, for the clearinghouse
JSONmanifest.jsonThe inventory and its hashes, with the engine versions
HTMLindex.htmlAn offline landing page for the whole package
Push to EHRover the manifestSend to clearinghousestaged locally in the pilotDownloadthe package
Before it goes, eight checks on the claim’s own fields
- Member ID on the claim
- Payer routing ID, not a placeholder
- Billing NPI, ten digits
- At least one diagnosis
- Service lines with codes and charges
- Dates of service
- No unresolved duplicate
- Diagnosis pointers that resolve
Guarded
Each entry is sealed to the one before.
A session’s audit trail is a hash chain: every entry carries the fingerprint of the one before it, so none can be changed without breaking every link after it.
PHI encrypted at restAES-256, keys rotated every 90 days
Session audit trailAn immutable hash chain
Break-glass accessNone this session
- Encounter opened
- Codes drafted
- Checks run
- Claim confirmed
- Package exported
Questions
What a coding director asks first.
Does Sync send a claim by itself?
No. It proposes and a person confirms. Export never raises a code on its own, and delivery to the clearinghouse is staged locally in the pilot.
What does it check?
On every claim: the NCCI procedure-to-procedure edits, the E/M level from medical decision making, documented work the claim leaves out, the revenue against the fee schedule and a clean-claim score. On export, eight checks on the claim’s own fields, from the member ID to the diagnosis pointers.
How does it set the E/M level?
From the note, on the two-of-three rule: the problems addressed, the data reviewed and analysed, the risk of what was decided. In the emergency department the level comes from decision making alone; time does not count.
What happens when something is missing?
It says so. An unknown payer is priced at 1.80× Medicare and the multiplier is shown beside the figure. Without the hospital’s own coding there is no baseline, so no uplift is claimed.
What leaves with the claim?
A FHIR R4 bundle, a PDF summary, the scrub report, the X12 837 claim, a manifest of hashes and engine versions, and an offline index of the whole package.
Where does it run, and who can see what?
On VAS, the system underneath every V3ra product. PHI is encrypted at rest with AES-256, keys rotate every 90 days, and every entry in a session’s audit trail is sealed to the one before.
V3ra Platform · Sync
See a claim built, checked and sent.
One encounter, from the codes drafted at the bedside to the package that leaves, on the platform as it runs today.