eRaktKosh reporting without the re-typing
The bags, TTI results and issues your staff record during the normal day are mapped to the eRaktKosh schema and submitted on schedule, with the acknowledgement stored against every record.
MOHFW collection-summary
Schema validation before send
Stock endpoint the portal polls
Parallel eRaktKosh registers
How the reporting works
Submission is a background process rather than a monthly scramble.
Monthly Collection Summary
Built from the bags already entered and submitted on a schedule you set, rather than compiled into the portal by hand.
Validated before sending
Records are checked against the national schema first, so problems surface in your queue rather than as a rejection.
Acknowledgements retained
Every accepted record keeps its acknowledgement, so you can evidence what was filed and when.
Rejections handled
Rejected records are surfaced with the reason, corrected in place and resubmitted in the next batch.
Full submission history
Every batch, its period, record count and outcome, retained and searchable.
Reconcile against your own registers
Compare what the eRaktKosh Data export says against your Donor and Issue Registers, for any date range.
From bags already entered to the national return
Credentials in Settings
Hospital code, shared key and OAuth client sit under Integrations. Generate a token from the same screen — no vendor login on your behalf.
Payload from operational bags
The monthly collection summary is built from bags, TTI results and issues your staff already recorded. There is no second register maintained for the portal.
Validate, then send
Controlled-vocabulary and arithmetic checks run locally. A mismatch surfaces in your queue instead of as a rejection weeks later.
Portal reply on the screen
The API response is shown while you are still on the submission. Tested stock is exposed on a separate endpoint eRaktKosh polls between monthly returns.
What the sequence looks like
- Your working day bags, tests, issues
- Mapped to the eRaktKosh schema
- Validated before sending
- MOHFW API
- Reply on the same screen
Trigger Sent in one action, when you send it
The other way: eRaktKosh pulls public availability
- eRaktKosh
- Tested stock at your centre
Reporting is a by-product of the work, not a second job
When reporting is a separate exercise it gets done from the registers, late, by whoever is free that evening. The errors are found weeks later by somebody else.
- The data submitted is the same data your staff entered while doing the work
- No parallel register maintained purely for the portal
- Discrepancies between stock and submissions are visible immediately
The measure of an eRaktKosh integration is what happens when it fails
Every vendor in this category will tell you they support eRaktKosh. The claim is close to meaningless on its own, because it covers everything from a real API submission built out of your own records down to a support engineer logging into the portal on your behalf once a month. The question that actually separates them is what happens to a rejected batch: where the rejected records appear, what reason is shown against each one, how a correction is made, and when it goes back. If the answer is that the vendor handles it, you have bought a service dependency, and in March when their team is stretched it is your return that is late.
Rejections cluster into a small number of causes, and almost all of them are mapping rather than data problems. Controlled vocabulary mismatches are the largest group by a distance: blood group, component name, donation type and deferral reason all have to match the values the national schema accepts, exactly. Then date and period errors, duplicate unit numbers, arithmetic that does not close because components separated exceed collections, mandatory fields that are optional in your own workflow, and stale licence details after a renewal. Because these are systematic, they are fixable once in configuration instead of row by row every month, which is the whole argument for validating locally before sending.
The other half of doing this properly is reconciliation, and it is the half that gets skipped. Once a month, before the next period opens, the collections in your Donor Register should be compared against the collections in the submission, split by voluntary and replacement and by in-house and camp; TTI results against reported screening counts; components prepared against the Component Preparation Record; and issues and discards against their registers. If your system can produce that comparison for any date range it is a ten-minute job. If it cannot, it is a day, which is why it does not happen, which is why the discrepancy gets found by an inspector instead of by you.
Questions about eraktkosh integration
Is eRaktKosh integration mandatory for blood banks in India?
Reporting into eRaktKosh is expected of licensed blood centres, so the real question is not whether you report but how the data gets there. The three routes are manual entry into the portal, bulk spreadsheet upload, and direct submission from your blood bank management system. Only the third makes reporting a by-product of the work rather than a second job, and only the third keeps the public stock position current between monthly returns.
Why do eRaktKosh submissions get rejected?
Most often a controlled vocabulary mismatch, a blood group, component name, donation type or deferral reason that does not match the value the national schema expects. After that: dates outside the reporting period or in an unaccepted format, duplicate unit numbers, internal arithmetic that does not close such as components exceeding collections, missing fields that are mandatory nationally but optional in your workflow, and stale licence details after a renewal. RAKT validates against the schema before sending, so these surface in your queue rather than as a rejection weeks later.
Does RAKT submit to eRaktKosh automatically?
Yes. The Collection Summary is built from the bags, test results and issues your staff recorded during the ordinary working day, validated against the national schema, and sent to the MOHFW API from the screen you are already on. The portal reply appears immediately. Separately, eRaktKosh polls a tested-stock endpoint so public availability stays current between returns. The donor list exports in the portal upload format with the same preflight checks.
Is eRaktKosh the same as ABDM or ABHA?
No. eRaktKosh is national reporting and public stock. ABDM is the digital health mission, and ABHA is the individual health identity used at registration. In RAKT, eRaktKosh removes the monthly re-typing job; ABHA resolves a donor to a verified identity so demographics and history inside your network stay reliable.
More of what RAKT does
See this running on your own floor
Tell us how your centre works today and we will show you the parts that would change.