eRaktKosh Data Entry Fields to Reconcile

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.²

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.

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.

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.

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.

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.

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.

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.

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.

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.

The exception log supports your investigation but does not replace the underlying statutory records. Schedule F Part XIIB 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 data-entry guidance no public URL
2. eRaktKosh national portal eraktkosh.mohfw.gov.in
3. National Blood Transfusion Council, Standards for Blood Banks and Blood Transfusion Services no public URL
4. Drugs and Cosmetics Rules, 1945, Schedule F Part XIIB, sections I and L cdsco.gov.in