eRaktKosh Integration: A Practical Guide for Indian Blood Centres

Every licensed blood centre in India reports into eRaktKosh, the national blood bank network run under the Ministry of Health and Family Welfare through the Centre for Development of Advanced Computing. What varies enormously between centres is how the data gets there, and that difference is usually worth several working days a month, plus the errors that come with doing the same work twice.

This guide covers what eRaktKosh expects from you, the three ways centres actually get data into it, why submissions get rejected, and how to reconcile what the portal holds against your own registers. It is written for the person who actually files the return.

What eRaktKosh is, and what it is not

eRaktKosh is a centralised blood bank management and reporting network. It gives the public a view of blood availability across participating centres, gives state and national authorities aggregate visibility of collection, stock and utilisation, and gives each centre a portal through which it reports its own activity.

It is worth being precise about what that does and does not make it. eRaktKosh is a reporting and visibility layer. It is not an operational system for running a blood centre, and treating it as one is the single most common mistake we see at centres coming off paper. The portal will not refuse to issue an untested unit, will not hold your crossmatch record, will not compute an NABH performance indicator, will not manage component expiry, and will not stop the same bag being written into nine separate registers by hand. Those are the jobs of a blood bank management system, and eRaktKosh assumes you have solved them somewhere.

The corollary matters too: for a very small, low-volume centre with one licence and no component preparation, the portal plus genuinely disciplined paper registers is a defensible arrangement, and anyone telling you otherwise is selling something. The arrangement stops being defensible the moment you prepare components, run camps, hold more than one licence, or aim at accreditation.

What a centre is expected to report

The precise field list and template have changed more than once and will change again, so treat the following as the shape of the obligation rather than as a schema reference. Broadly, a reporting centre is expected to keep current:

• Centre and licence details: the licensed entity, its category, its address and its licence validity, kept accurate as renewals happen.
• Collection activity: donations by period, split by voluntary and replacement, and by whether they were collected in-house or at an outdoor camp.
• Donor demographics in aggregate, including the age and sex distribution and first-time versus repeat donation.
• Testing outcomes: the mandatory transfusion-transmissible infection screen for HIV, hepatitis B, hepatitis C, syphilis and malaria, reported as counts rather than as identifiable results.
• Component preparation: what was separated from whole blood, by product type.
• Stock position: available units by component and blood group, which is what feeds the public availability view and therefore the part most visibly wrong when it is stale.
• Issue and utilisation: units issued, and the discard count with its cause.

Two obligations sit underneath all of this and are easy to miss. The first is that the stock position is meant to be current, not monthly: a public availability view that says you hold six units of O negative when you hold none sends a patient’s family to the wrong building. The second is that the eRaktKosh return has to agree with the statutory registers you keep under Schedule F Part XII-B of the Drugs & Cosmetics Act, 1940. Two sets of numbers that disagree is a finding, and it is the finding a district inspection most reliably produces.

The three ways centres get data in

1. Manual entry into the portal

Somebody sits with the registers at the end of the month and types the aggregates into the portal. It requires no software and no integration, which is why most centres start here.

The costs are predictable. It is slow, and it happens late: typically in the last week, by whoever is free that evening rather than by whoever knows the data. It also introduces a class of error that is almost impossible to find afterwards, because the only way to check a typed aggregate is to recompute it from the registers by hand. Worse, it produces a stock position that is accurate on the day it is entered and drifts every day after, so the public availability view is wrong for most of the month by construction.

2. Bulk upload from a spreadsheet

An improvement, and where a lot of centres sit. Data is assembled into the prescribed spreadsheet format and uploaded, which removes the typing but not the assembling. The upload is where most people first meet the validation layer, and it is unforgiving in the way schema validation always is: a date in the wrong format, a blood group written O+ve where the schema wants O POSITIVE, a component name that does not match the controlled vocabulary, or a unit number that already exists will each fail a row or a whole file.

The trap is that a bulk upload is still a parallel record. You are maintaining your operational registers and a second representation for the portal, and the two drift. Whenever a correction is made in one and not the other, the reconciliation problem you were trying to avoid is back, with an extra file in it.

3. Integration from your blood bank management system

Your staff already record the bag at collection, the grouping and TTI results, the components separated and the units issued. That record is what gets mapped to the eRaktKosh schema and submitted, in one action, with no second entry anywhere.

This is the only one of the three where reporting is a by-product of the work rather than a second job. It also changes what the failure modes are: instead of typing errors you get mapping and validation errors, which are far better failures to have because they are systematic. A wrong mapping fails the same way every time and is fixed once; a typing error is different every time and is found by nobody.

If you are evaluating vendors on this, the question that separates real integration from a checkbox is not “do you support eRaktKosh”. It is “what happens when a batch is rejected”. A useful answer names where the rejected records appear, what reason is shown against each, how a correction is made in place, and when it is resubmitted. An answer that amounts to “our support team handles that for you” is a service dependency dressed as a feature, and in March, when their support team is busy, it is your return that is late. How RAKT does this is a reasonable benchmark to hold others to.

Why submissions get rejected

Rejections cluster, and almost all of them are one of six things:

1. Controlled vocabulary mismatches. Blood group, component name, donation type and deferral reason all have to match the values the schema accepts, exactly. This is the single largest category, and it is entirely a mapping problem, which is why it should be fixed once in configuration rather than corrected row by row every month.
2. Date and period errors. A collection date outside the reporting period, an expiry before a collection, or a date format the parser rejects. Component expiry computed from the wrong parent bag shows up here.
3. Duplicate unit numbers. Usually a resubmission of something already accepted, or two centres under one licence numbering independently and colliding.
4. Arithmetic that does not close. Components separated exceeding collections, issues exceeding available stock, discards not accounted for. The portal checks internal consistency, and a centre that maintains its stock position separately from its issue records will trip this repeatedly.
5. Missing mandatory fields that are optional in your own workflow. The usual culprits are donor demographic fields and the collection venue on a camp donation.
6. Stale licence or centre details. After a licence renewal, submissions can fail on the centre record rather than on anything in the data, which is a genuinely confusing hour if you are looking at the rows.

The practical discipline: validate before you send. Checking records against the schema locally turns a rejection weeks later into a queue item today, and the difference is not administrative, a rejected batch discovered in the following month means the month you already closed does not match what the national record holds.

Reconciling the portal against your own registers

Whichever route you use, reconcile. Do it monthly, before the next period opens, and do it on four figures:

• Collections in your Donor Register against collections in the submission, split by voluntary and replacement and by in-house and camp. Camp collections are where this most often diverges, because camp data is the most likely to have been entered late.
• TTI results in your TTI Register against reported screening counts. A mismatch here usually means reactive units were handled outside the normal flow.
• Components prepared against your Component Preparation Record. One collection becoming three or four products is the most common source of double counting in either direction.
• Issues and discards against your Issue Register and Discard & Disposition Register. Discards are the figure most often understated, because a discard is a small administrative act at the end of a shift and the register entry gets deferred.

If your system can produce that comparison for an arbitrary date range, this is a ten-minute job. If it cannot, it is a day, which is why it does not get done, which is why the discrepancy is found by an inspector instead.

eRaktKosh and ABDM are not the same obligation

These get conflated constantly, and they pull in different directions. eRaktKosh is reporting: aggregate activity and stock, flowing from you to the national record. ABDM, the Ayushman Bharat Digital Mission, is identity and interoperability: a way for a donor’s or patient’s records to be recognised across the health system. ABHA is the individual health identity inside it.

For a blood centre the practical difference is that eRaktKosh integration affects your reporting workload, while ABHA affects your registration desk and what follows a donor between centres. Most usefully, deferral history, which is a donor-safety matter and not a paperwork one. Both are moving in the same policy direction, and both are considerably cheaper built in than retrofitted onto a system that was not designed for them.

A checklist before your next submission

• Centre and licence details current, including validity dates after any renewal.
• Blood group, component, donation type and deferral vocabularies mapped to the values the schema accepts, checked once in configuration rather than per row.
• Camp collections entered and reconciled into centre stock before the period closes.
• Component preparation derived from parent bags, so separation cannot exceed collection.
• Discards recorded with cause and approval, not left to the end of the month.
• Validation run locally before submission, with failures queued and reasons visible.
• The portal response for each submission saved with your monthly file, so you can evidence what was filed and when.
• The four-figure reconciliation above completed and any variance explained in writing.

None of this is difficult. It is just work that compounds when the reporting representation and the operational record are the same thing, and multiplies when they are not.

eRaktKosh: the questions we are asked most