Not an HMSThe revenue layer above the one you already run — orchestration for hospitals, health aggregation for employers.See the difference →

Your HIS has a claims module.
That is not the same as revenue integrity.

Recording what a payer decided and predicting what a payer will decide are different engineering problems. Most hospital systems solve the first one well. Here is how to tell, in three questions, which one yours solves.

NADI · DRAPTO
● Platform 27 modules
● Rules 24, rationale attached
● Figures worked arithmetic
✓ watched to the bank

The screen

Your HIS records that a claim was reduced. This is the part that runs before the bill is raised, while the room can still change.

This page is not an argument that hospital information systems are bad at claims. Many are good at claims. It is an argument that the job they do — hold an accurate record of what was submitted, what came back, and what was received — is a different job from the one that stops a deduction happening. If your system already does both, you do not need us, and this page will tell you how to check rather than asking you to take our word for it.

The distinction

Same claim. Two different jobs.

The room-rent entitlement checked at admission
Same claim, two different jobs. This is the one an HIS claims module never does.

Every row below is something that happens to a single claim. The middle column is what a system of record is built to do with it. The right column is what deciding differently requires.

Same claim. Two different jobs
Moment in the claimSystem of recordRevenue integrity
Room allotted at admissionRecords the room and the rateChecks entitlement against the policy first, and models the proportionate deduction the choice will cause
Pre-authorisation raisedStores the reference and the responseTracks the notification clock against the payer's own limit and escalates before it lapses
Procedure codedHolds the code that was enteredScores the code against the documentation actually on file for the queries it will attract
Bill assembledTotals the linesSeparates payable from non-payable consumables before the bill reaches the payer
Tariff appliedApplies the rate card loaded into itCompares that rate card against the payer's current revision and reports the drift
Claim submittedConfirms it went, records the acknowledgementEstimates the shortfall the submission is carrying, before it is sent
Settlement advice receivedRecords billed, paid and disallowedSplits the disallowance into predictable and unexplained — the second is the appeal list
Deduction acceptedCloses the claimFeeds the cause back so the same deduction is caught at admission next time

Three questions for your vendor

You do not need our opinion of your system. You need theirs, on the record. Ask these in a demo and watch which produce a screen and which produce an export.

  • Show me last month's deductions split into predictable and unexplained. Predictable means the rule was knowable before submission — a room cap, a sub-limit, a waiting period. Unexplained is the appeal list. If the split does not exist, nobody is appealing on evidence.
  • Which of my current tariffs is behind the payer's latest revision? Tariff drift is silent, compounds every revision, and is invisible in any report that assumes the loaded rate card is correct.
  • At admission, what will this room cost this patient under this policy? This is the one that separates the categories. It has to be answerable at the counter, by the person allotting the room, before the patient is in it.
Model a room-cap deduction →
Answer is a screenShown live, on your data, at the moment of the decision
Capability
Answer is a reportAvailable after month end, from the settlement advice
Record
Answer is an export“You can pull the data and build that in Excel”
Gap
Answer is a roadmap“That is coming in the next release”
Ask when
Why the gap exists

It is structural, not negligence.

A hospital information system serves every department in the building. The claims module competes for roadmap against pharmacy, theatre scheduling, diet, stores and the NABH file. It wins that competition often enough to record claims correctly and rarely enough to model a payer's contract, because modelling a contract means maintaining every payer's tariff revisions, room-cap arithmetic, sub-limit tables and notification windows — permanently, as they change, for every payer you deal with.

That is a full-time job for a product, not a module. It is also why the honest version of this page cannot name a vendor: the constraint applies to the category, and any specific claim about a specific product would be out of date by the next release.

A deduction you predicted is a decision you can still change.

A deduction you recorded is a number you are explaining to the owner after the money has gone. Every mechanism on this page exists to move claims from the second category to the first.

What we do not do

Worth saying plainly, because the category is full of migration projects sold as analysis projects.

  • We do not replace your HIS. Drapto reads from what you run. Your clinical records, your registers and your existing workflows stay where they are.
  • We do not hold your data hostage. Exports are yours, in open formats, at any time.
  • We do not sell you leads or take a cut of a consultation. The appointment half is free and stays free; the paid product is revenue integrity, sold to the hospital.
  • We do not claim a recovery percentage. We will not publish one, because it depends on your payer mix and anyone quoting a number without seeing your settlement advices is guessing.
Runs alongsideNo migration, no rip-and-replace
Yes
Reads your settlement advicesTwenty settled claims is enough to start
Yes
Replaces your EMRDifferent job, different system
No
Publishes a recovery %Depends entirely on your payer mix
No
Questions

Straight answers.

Are you saying HIS claims modules are bad?

No. A claims module that records submission, status and receipt accurately is doing a hard job well, and some do it very well. The question is not quality, it is category. Recording what a payer decided and predicting what a payer will decide are different problems, and a system built for the first is rarely asked to solve the second.

Do I have to replace my HIS to use Drapto?

No. Drapto reads from what you already run and sits alongside it. If a vendor tells you revenue integrity requires replacing your hospital information system, that is a migration project being sold as an analysis project.

My vendor says the claims module already flags deductions. Is that the same thing?

Ask which ones and when. Flagging a deduction after the settlement advice arrives is reporting — useful, but the money has gone. The distinction that matters is whether the system tells you at admission that this room, for this policy, will attract a proportionate deduction. Ask for that specific screen.

What if the answer is that I do not need you?

Then that is the answer. If your system already splits last month's shortfall into predictable and unexplained, and your tariffs are checked against the payer's current revision, you have the capability and buying it twice would be waste.

Does this apply to a 30-bed hospital or only large ones?

It applies wherever claims are a material share of revenue. Smaller hospitals often feel it more sharply, because there is no dedicated billing analyst absorbing the gap manually.

Bring twenty settled claims.

We will split the deductions into predictable and unexplained and show you the working. If your existing system already does that, you will find out for free and we will say so.

Free deduction audit See revenue integrity →

Built to standards, not to a demo

ABDMABHA linking, consent flows
FHIR R4Records and claim bundles
NHCXBundles built & validated
DPDPConsent and purpose limitation
Indian data centresHosted in Indian data centres
Offline codingNo API key, no per-call cost

Corporate contracts, without changing your system.

We find the companies and run the outreach. Your existing software stays where it is.