eRaktKosh Data Entry Fields to Reconcile

Check your eRaktKosh data entry fields against the record that first captured each value. Take one donation-unit number and compare the donor registration and screening records, collection record, grouping and TTI worksheets, component preparation record, and issue, transfer or discard record with the corresponding portal entries. Use the same centre and reporting cut-off on both sides.

A connected eRaktKosh account can still hold records that your centre cannot reconcile. The portal blood-centre ID, donor and visit identifiers, donation-unit number, grouping and TTI status, parent and child component identifiers, and final stock disposition must all describe the same transaction chain. The portal’s blood-bank workflow links those records through identifiers and dated status changes.¹

Use the current portal screen and user manual as the final authority for fields marked mandatory.¹ The checklist below isolates the fields that connect one workflow stage to another. That distinction matters because eRaktKosh publishes blood-centre and blood-availability information, so an incomplete status chain can become a stock-reporting problem.²

For every entry or correction, identify three things before you type: the source record, the field on that record and the identifier that connects it to the portal transaction. A value copied from a local summary or an earlier eRaktKosh download remains a secondary copy. Reconcile it against the donor, collection, testing, component, inventory or issue record created for the underlying event.

A connection answers only one question

A successful connection proves that your system can communicate with eRaktKosh. It does not prove that the portal recognised the centre, attached the transaction to the correct unit or moved that unit to the intended status.

Separate your checks into three layers:

• Transport: Was the transaction sent, and what exact response came back?
• Identity: Did the centre ID, unit number and component identifiers match existing portal records?
• State: Did the accepted record reach the expected testing, stock or disposition status?

The eRaktKosh integration guide covers connection and system preparation. On the floor, prove one unit from donor visit to final disposition before you treat a successful login or upload as a completed integration.

Fields to reconcile by workflow

The eRaktKosh user manual separates data entry into linked donor, collection, testing, component, inventory and issue workflows.¹ Compare the following fields even when your local software uses different labels. The third column names the source record you should open before entering or correcting each group.

Your reconciliation sheet should show the portal field, portal value, source record, source value and the identifier used to join them. Add the operator, comparison date and reporting cut-off. This makes the first mismatch visible without turning a portal download into a substitute source record.

This is a reconciliation list, not a substitute for every field displayed on the current portal screen. Your control must catch both a blank required field and a populated field attached to the wrong identifier.

Open the source record before changing the portal entry. The source may be paper or electronic, but it should be the record created when your staff performed that workflow step, not a later spreadsheet copied from eRaktKosh. Schedule F Part XIIB, section L, remains the statutory reference for the records your blood centre must maintain.³

For each exception, place the source value, local software value and portal value side by side. Mark the first field where they diverge. A downstream difference often follows from that first broken identifier or status.

Use the event record for event fields. Donor registration supports donor details, the collection record supports the donation event, the authorised worksheet or register supports a test result, the component preparation record supports a prepared component, and the issue, transfer or discard record supports the final disposition. The stock register confirms the resulting inventory state; it should not be used to reconstruct a missing issue or discard entry.

Keep donor, visit and unit identifiers separate

A donor identifier represents the person, a visit or registration identifier represents the present attendance, and the donation-unit number identifies the collected unit. NBTC standards require traceability from donor to recipient and back through the associated records.⁴ Collapsing these identifiers makes a returning donor look like a duplicate donation or leaves the new unit attached to an earlier visit.

Compare name, age or date of birth, gender, contact details and address with the donor registration record. Compare the visit date and eligibility outcome with the current attendance, questionnaire and medical examination record. When your local record stores date of birth but the portal shows age, use the visit date for the comparison rather than the donor’s age on the day you investigate the mismatch.

If the donor is deferred, keep the outcome, reason and applicable period with that visit. A paper-only entry creates the return problem described in donor deferral records that work on return.

Map the camp before reconciling its collections

Your local camp code must point to the intended portal camp and centre. Compare the date, venue and organiser as well as the name, since abbreviated camp names can look identical when staff select them from a list.

The portal entry should remain traceable to your local blood donation camp documentation. If fifty collection records fail under one camp mapping, correct the mapping before editing fifty units individually.

Reconcile collection from the unit record

Start with the donation-unit number on the collection record and bag label, then check that the same number is attached to the correct donor visit in eRaktKosh. Compare the collection date and time, bag or collection type, volume and collection outcome only after that identity link agrees.

Leading zeros, prefixes and separators are part of the identifier when your centre uses them. If the local collection record and label carry one format while the portal carries another, record the discrepancy before correcting it. Do not begin with a component record that inherited the altered number.

For a camp collection, also reconcile the camp ID and centre ID. A correct unit number under the wrong camp still leaves the portal transaction attached to the wrong collection event.

Link grouping and TTI results to the collected unit

Schedule F Part XIIB requires every donation to be tested for HIV-1 and HIV-2 antibodies, hepatitis B surface antigen, hepatitis C virus antibody, VDRL and malarial parasites.³ For reconciliation, each result and the testing-completion status must sit against the same donation-unit number.

Open the grouping worksheet or register, TTI worksheet or register and unit master record together. Compare the donation-unit number before you compare ABO group, Rh(D), individual TTI results, result date and completion status. This prevents a correct result from being accepted against the wrong unit.

Do not treat a completed local worksheet and a pending portal status as equivalent. Compare the unit identifier, result value, test date and completion status together. Your TTI testing records should remain the traceable source when you investigate a portal mismatch.

Preserve the parent-child component link

Each prepared component needs its own identifier while retaining the parent donation-unit number. A component sent under a reformatted parent number, such as 417 instead of 000417, can no longer be reconciled reliably by identifier.

For each child component, compare the component preparation record, parent label, component label and portal entry. The component type or code, component identifier, preparation date and time, volume, expiry and current status should all belong to the same parent unit.

Map local component names to the portal values before transmission. Do the same for preparation, expiry and status fields instead of asking an operator to reinterpret them during portal entry.

Reconcile status, not just the unit count

The national portal provides blood-availability searches.² Compare available, issued, transferred and discarded records separately instead of checking only the total number of components.

For an issued component, open the issue register and supporting requisition. For a transfer, use the transfer note and receiving or dispatch record. For a discard, compare the discard record, reason and recorded date and time with the portal disposition.

Two totals can agree while containing different component types, blood groups or final statuses. This is one reason the same unit can appear available locally after it was issued in the portal, or remain available in the portal after your technician discarded it. The controls in common blood inventory mistakes apply to this comparison as well.

Correct the source record and portal record separately

A correction in eRaktKosh changes the portal record. It does not amend the donor form, collection register, testing worksheet, component preparation record, stock register or issue record held by your centre. If both copies contain the same wrong value, changing only the portal leaves the source record wrong.

First decide which record contains the error. Correct a wrong source record under your centre’s approved document-control process, retaining the original value and correction trail required by that process. Then update or resubmit the portal transaction through the action available to your authorised role in the current eRaktKosh screen and official guidance.¹

Treat portal submission and statutory record maintenance as two connected controls. An eRaktKosh acknowledgement confirms what the portal accepted. It does not create, amend or replace the records maintained by your centre under Schedule F Part XIIB, section L.³

Assign the correction before anyone edits it

Put a named owner against every exception. Role titles differ between centres, so your SOP should identify who can authorise a source-record correction, who maintains the local mapping and who is permitted to submit or correct the eRaktKosh transaction.

The operator entering data in eRaktKosh should not decide alone that an authorised worksheet is wrong. Send the exception to the owner of that source record, keep it open and submit the corrected portal value only after the required source decision or mapping correction has been recorded.

Do not change a correct paper or electronic source merely to make it agree with an incorrect portal entry. Equally, a portal screenshot showing the corrected value does not complete a controlled correction to the source record. Your exception log should connect the two actions without treating either one as a substitute for the other.

Keep the title or version of the eRaktKosh user manual used, the date you accessed it and the portal role under which the correction was attempted. That gives the next technician enough context when the current screen, mandatory fields or available actions differ from an older local instruction.

Hand stock-balance differences to the stock-entry check

Keep using this field guide when an individual portal record differs from the donor, collection, testing, component or disposition record at your centre. Find the first mismatched field and repair that transaction chain.

If the individual component records agree but opening stock, additions, issues, transfers, discards or closing stock differ at the chosen cut-off, move to the dedicated eRaktKosh stock-entry reconciliation check. That comparison follows stock movements and reporting cut-offs; it should not be replaced by editing otherwise correct unit-level fields until the total happens to agree.

Why records are rejected or left incomplete

Do not keep one general “eRaktKosh error” queue. Classify each exception by what actually happened:

Identifier and workflow dependencies should be checked before staff re-enter a rejected transaction. Retyping can create a second representation of the unit while leaving the original fault unresolved.

Frequent places to inspect include leading zeros removed from unit numbers, a component submitted under the wrong parent, a local abbreviation mapped to the wrong portal value, and a final disposition recorded locally but never submitted. For a wider chain check, follow the same identifiers through your donor-to-recipient traceability records.

A reconciliation routine for each exception

1. Fix the scope. Select one centre, a defined date range and one workflow stage. Record the cut-off time used for both local and portal reports.
2. Keep the response. Save the exact rejection text, transaction reference or screen result. “Upload failed” is not enough for another technician to reproduce the problem.
3. Compare identifiers in order. Start with the portal centre ID, then donor or visit ID, donation-unit number, parent unit and component identifier.
4. Find the earliest divergence. If the collection record is absent, do not begin by editing the component. If collection exists but the component does not, compare the parent key and component mapping.
5. Correct the source or mapping. Amend the local record when it is wrong. When the mapping is wrong, correct that mapping and resubmit according to the portal procedure rather than typing a separate version solely to make the count agree.
6. Replay in workflow order. Follow the data-entry sequence in the current eRaktKosh guidance so that each downstream record has the parent record it needs.¹
7. Verify the record and the total. Confirm the individual unit or component first, then compare totals by component, blood group and current status.
8. Close the exception. Record the old value, corrected value, operator, date and time, resubmission result and final portal status.

Before closing the exception, return to the source record for the affected workflow. A portal screenshot proves the corrected portal state; it does not prove that your donor, collection, testing or component record carries the same corrected value.

The exception log supports your investigation but does not replace the underlying statutory records. Schedule F Part XIIB, section L, lists the records a blood centre must maintain and requires them to be kept for five years; its closing note names no start date for that period.³ Keep the portal correction trail alongside the relevant records covered by your blood bank record-retention procedure.

Keep one operational version of the record

With RAKT eRaktKosh reporting, the control to test is straightforward: one donor visit, donation unit, component and final status should carry unchanged from your operational record into the portal. Your centre remains responsible for checking mappings, resolving exceptions and retaining the supporting records.

Software cannot repair an identifier that was changed on paper before entry. It can make the mismatch visible and remove the need to hand-count a second stock register, provided your staff correct the first broken link instead of entering another version of the unit.

Before closing a reconciliation batch, confirm:

• The portal centre ID matches the intended centre.
• Donation and component identifiers retain their full format, including leading zeros.
• Camp collections point to the correct camp record.
• Grouping and all TTI entries belong to the same donation unit.
• Every component retains its parent unit identifier.
• The latest issue, transfer or discard event is reflected in the current stock status.
• Every rejection has an owner, correction record and verified outcome.

Sources

1. eRaktKosh Blood Bank User Manual and official data-entry guidance, available through the eRaktKosh portal eraktkosh.mohfw.gov.in
2. eRaktKosh, Ministry of Health and Family Welfare, Government of India eraktkosh.mohfw.gov.in
3. Drugs and Cosmetics Rules, 1945, Schedule F, Part XIIB, including section L, Central Drugs Standard Control Organization cdsco.gov.in
4. Standards for Blood Banks and Blood Transfusion Services, National Blood Transfusion Council and National AIDS Control Organisation naco.gov.in