Every bag traced from donor to transfusion — and the register writes itself
Shonit is cloud blood bank management software that runs the whole floor: camps and donors, bag entry, component preparation, TTI screening and grouping, tested stock, crossmatch and issue. The registers, MIS reports and performance indicators are built from the work your staff already do — not compiled the weekend before an inspection.
Runs in a browser · no client to install Deployable on infrastructure you control Serving [NUMBER OF CENTRES] blood centres
| Component | A+ | A− | B+ | B− | O+ | O− | AB+ | AB− | Total |
|---|---|---|---|---|---|---|---|---|---|
| WB | 0 | 0 | 3 | 0 | 0 | 0 | 2 | 0 | 5 |
| PRBC | 6 | 2 | 31 | 0 | 44 | 1 | 10 | 2 | 96 |
| FFP | 36 | 4 | 64 | 4 | 37 | 4 | 13 | 4 | 166 |
| PLC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Total | 42 | 6 | 98 | 4 | 81 | 5 | 25 | 6 | 267 |
Trusted by the centres that run on it
Hospitals, standalone blood centres and multi-centre networks. Logos below are placeholders until each institution's written permission is on file.
Every [N] above is a placeholder. Replace with verified figures before publishing — nothing here is invented.
The portals your centre reports into, and the standards it is inspected against
Shonit is built around the outputs an Indian blood centre is actually asked for. The records created during an ordinary shift are the same records an assessor, a state blood transfusion council or a national portal wants to see — so nothing is compiled twice.
eRaktKosh data
An eRaktKosh Data report and a custom register, built from the bags, tests and issues already recorded — not re-keyed into a portal from a printout.
ABHA identity
Donors can be registered through an ABHA-verified flow, so demographics arrive with the health account instead of being read off a card and typed at the desk.
Performance indicators
TTI reactive rate, adverse transfusion and donor reactions, issue turnaround, voluntary share, outdated units, deferrals and QNS — computed over any date range from your own record.
Statutory registers
Donor, TTI, grouping, component preparation, issue, crossmatch, disposition and discard records maintained continuously, in your assessor's format.
What an inspector asks for already exists. See how compliance works
The same screens your staff already move through
Not a diagram of the blood lifecycle — the actual sequence in Shonit, from a camp donor at the registration desk to a unit issued against a hospital request. Every step writes to the register it belongs to as it happens.
Donor registration
Camp or in-houseA donor is registered at the centre, at a camp, or through a shareable self-registration link the camp organiser can circulate as a URL or QR code. Profile details and the medical questionnaire are captured on two screens, and the donor's history — past donations, deferrals, adverse reactions — is attached to the same identity rather than started afresh.
Shonit works to a 90-day re-donation interval for whole blood: a donor's next eligible date is calculated from their last donation, and recent donors are flagged as not yet due before the needle rather than after.
Bag entry
Camp reconciliationBags are entered against the camp or in-house session they came from, so a day's collection reconciles back to the centre against the camp it was collected at. Bag numbers are unique per centre and Shonit refuses a duplicate; volume must be positive and a collection date cannot be in the future.
“Bag number is already in use” is a refusal, not a warning. Every downstream component carries its parent bag number, which is what makes a unit issued next month still trace back to the donor who gave it.
Component preparation
One bag in, several outBlood processing splits a bag into its components, component volume records what each one yielded, and each component gets its own expiry. Shonit handles whole blood, PRBC, FFP, PLC, RDP, SDP and cryoprecipitate, and every component keeps the link back to its parent bag.
Components past their expiry date are swept out of available stock automatically — untested, tested, quarantined or allotted alike — instead of being discovered in a register later.
TTI screening
Reactive → quarantineTransfusion-transmitted infection screening is recorded in its own stage of the pipeline, with results entered per test and per bag. A reactive result is not a note in a column — it takes the unit out of circulation and the reactive case appears in the TTI Reactive Cases report and the TTI register.
Data-entry stages need a technician or above; validation needs a supervisor. The person who enters a result and the person who signs it off are separated by role, not by convention.
Blood grouping
Forward & reverseForward and reverse grouping are recorded separately, alongside phenotyping and irregular antibodies. Invalid group values are rejected at entry. Patient grouping is recorded the same way on the reception side, which is what a compatibility check later has to work from.
Corrections are kept: grouping corrections, TTI corrections and component corrections each have their own register, so a changed result leaves a trail instead of overwriting history.
Validation
Supervisor sign-offEach lab stage — component preparation, grouping and TTI — has its own validation step. Validation is where a supervisor confirms what a technician entered, and it is a separate permission, so the two cannot be the same click by the same person.
Validated is not the same as releasable. A validated component still has to be shifted to tested stock before any request can reach it.
Shift to tested stock
The release gateThis is the single gate between the lab and the counter. Until a component is shifted to tested stock it is not available to any blood request, however busy reception is. The shift is timestamped and appears in its own register and MIS report.
Shifting to tested stock requires a supervisor. There is no counter-level override.
Blood request & billing
ReceptionA hospital or a patient's relative raises a blood request at reception. Required fields are enforced at creation, the bill is raised with payment modes, discounts and delivery charges, and the request ID is unique per centre. Bulk requests, fractionation and inward stock sit alongside it as their own tabs.
A discount cannot exceed the bill subtotal and a payment amount cannot be negative — the billing screen refuses the entry rather than producing an invoice that has to be corrected later.
Allotment
Compatibility enforcedUnits are allotted against the request from tested stock only. Shonit offers the components that are tested, in date and ABO/Rh compatible with the patient's own recorded grouping — oldest expiry first — and refuses anything outside that set.
“One or more selected units are not tested / compatible / available.” An allotted unit is reserved against that request alone; releasing it returns it to tested stock rather than leaving it double-counted.
Crossmatch
Per unit, not per requestCrossmatch compatibility is recorded for every allotted unit — compatible, ABO-compatible or incompatible. The compatibility report and the crossmatch labels print from the same record, and the crossmatch register is written as you go.
Every allotted unit needs a crossmatch result before issue, and a unit recorded incompatible cannot be advanced to issue at all.
Issue
Invoice + labelsIssue marks the chosen units as gone from available stock and prints the invoice, the compatibility report and the composite labels together. Each component leaves once — a unit already issued cannot be allotted to a second request.
Issue writes the Issue Register, the Patient-Recipient Register and the daily issue report in the same movement — there is no separate register-writing job at the end of the day.
Return, discard & reporting
Closing the loopA unit that comes back is returned to stock with the charges handled. Adverse transfusion reactions are recorded against the unit that was issued, graded per reaction. Discards need approval, and everything above rolls straight into the MIS reports and performance indicators.
Discarding components requires a supervisor. A discard is an approval, not a delete.
See where your blood centre stands at a glance
Open Shonit and the day is already summarised: units in stock, what expires this week, what was collected today and which requests are still open — before the first hospital call comes in.
- Current stock by component and blood group — switchable between tested and untested stock, exportable to Excel or PDF from the card itself.
- Near-expiry alerts — units expiring within seven days surface on the news strip while there is still time to rotate them.
- Open requests and pending serology — how many requests are waiting, and how many of them are stuck before grouping or crossmatch.
- Work completed today and revenue — bag entry, component preparation, TTI validation and issues, next to the day's billing.
- Available units by blood group — the chart a duty officer looks at before agreeing to a request.
One bag in, several components out — each with its own expiry
Blood processing records the split, component volume records what each bag yielded, and validation signs it off. Every component carries its parent bag number, so a unit issued next month still traces back to the donation it came from.
The checks Shonit runs, and will not let staff skip
Each of these is a refusal your staff actually see at the counter — the request fails with a reason, rather than a warning that can be clicked past. Every one of them is enforced in the server, not just hidden in the interface.
A validated component is not a releasable one. Until it has been shifted to tested stock, no blood request can reach it.
A reactive screening result takes the unit out of available stock and lands it in the reactive-cases report and the TTI register.
Expiry is checked when the unit is allotted, and expired units are swept out of stock on their own — not found later in a register.
Compatibility is checked against the patient's own recorded grouping before allotment — not discovered at the crossmatch bench.
Every allotted unit needs a crossmatch result, and a unit recorded incompatible cannot be advanced to issue.
Each component leaves once. A unit reserved against one request cannot be double-allotted to another.
Shifting to tested stock and discarding components both require a supervisor. Data entry needs a technician or above.
A bag number or request ID already in use is refused, and an ABHA already linked to another donor cannot be attached twice.
Negative ages and quantities, zero-volume bags, future collection dates and discounts larger than the bill are all rejected at entry.
Shonit also flags a donor who gave blood inside the last 90 days at registration, keeps grouping, TTI and component corrections in their own registers, and records who changed what against every record — so a question asked six months later has an answer.
Blood request, billing, allotment, crossmatch, issue
A hospital or a patient's relative raises a request. Reception bills it, serology records the patient's own grouping and allots units against it, crossmatch compatibility is recorded per unit, and issue prints the invoice, the compatibility report and the labels together.
Everything the counter actually has to handle
- Bulk requests for hospitals, issued straight from matching tested stock.
- Fractionation and inward stock — units received from another centre enter as tested stock with their own trail.
- Return to stock for a unit that comes back, with the billing handled rather than left dangling.
- Adverse transfusion reactions recorded and graded against the unit that was issued.
- Life-saving cases can bypass crossmatch — and the bypass is recorded as such, with who did it and when.
- Accounting — bills in and out, invoices, payment summaries, hospital credit and periodic cash reports.
Reporting is a product surface, not an afterthought
Pick a report, pick a date range, generate. Twenty MIS reports ship as standard cards, each printable, and a custom report builder covers the one your state asks for and nobody else does.
Around a hundred registers, in ten categories
Every entry lands in the register it belongs to as it is made. Filter by register, stock type and date range, search within it, and export to Excel or PDF. Nothing is compiled the weekend before an inspection.
- Blood Donor Record
- Multiple Venipuncture
- Master Record
- Issue Register
- Component Preparation Record
- Record of Component Supplied
- Accounting Register
- Patient-Recipient Register
- Transfusion Adverse Reaction
- Disposition Record
- Discard Register (Store)
- Camp List
- Age / Gender Distribution
- TTI-Reactive Distribution
- Blood Group Distribution
- Blood Bag Distribution
- Deferred Donor Distribution
- Projected vs Actual Collection
- Camp Sitewise Collection
- Post Camp Information
- Blood Bag List
- Component Preparation Record
- Reserved Components
- Discarded Components
- Expiring Components
- All Components (Shifted & Not Shifted)
- Shifted Components
- Not Shifted Components
- Shifted To Tested Stock (Timestamp)
- Less Quantity Bags
- Bags With Complications
- Component Corrections
- Grouping Register
- Forward Grouping
- Reverse Grouping
- Phenotyping
- Irregular Antibodies
- Patient Grouping Register
- Patient Forward Grouping
- Patient Reverse Grouping
- CBC
- Patient Irregular Antibodies
- Grouping Corrections
- TTI Register
- TTI Reactive Cases
- TTI Corrections
- Donor Register
- Repeated Donor List
- Deferred Donor List
- Adverse Donor Reactions
- SMS Report
- Life Saving Programme
- Deferred Donor Report (camp-wise)
- Daily Report
- Blood Issue Report
- Bulk Issue Report
- Bulk Issue (component-wise)
- Fractionation Report
- Inwarded Stock Report
- Inwarded Stock (component-wise)
- Adverse Transfusion Reaction
- Incorrectly Allotted Components
- Return To Stock
- Issue Register (Bulk Request)
- Issue Register (Blood Request)
- Issue Register (All Requests)
- Crossmatch Register
- Sample Receiving Register
- Deleted Requests
- Thalassemia Patients
- Patients
- Delivery Charge Summary
- Hospital Credit Summary
- Payment Summary (shift-wise)
- Discount Summary
- Reagent QC Register
- Other Items QC Register
- ABO Pooled Suspension QC Register
- Component Master QC Register
- PRBC / WB QC Register
- FFP / CPP QC Register
- PLC / PRP QC Register
- CRYO QC Register
- Absentee / Leave Register
- Staff Expiring Records
- Staff Members Attending Camps
- Staff Member Permissions
- Crossmatch Report
- eRaktKosh Data
- Your own register, built in the report builder
The record an assessor asks for is already written
Performance indicators are computed over whatever period you select, from the work your staff recorded — not estimated, and not assembled the night before. The same data produces the registers, the MIS reports and the eRaktKosh export.
- Nine performance indicators — TTI rate, voluntary donations, outdated WB/RBC, adverse transfusion and donor reactions, components prepared from whole blood, issue turnaround, deferrals and QNS.
- Any date range — the same indicators for a month, a quarter or an assessment window.
- SBTC and eRaktKosh outputs generated from the same records, so the numbers agree with each other.
- Graphs across accounting, camps, blood bags, donors, deferred donors, reception and TTI for the same period.
Shonit produces the records and indicators these frameworks call for. Accreditation itself is awarded to your centre by the assessing body — the software supports the submission, it does not confer the certificate.
What stops happening when the registers write themselves
Most centres come to Shonit from paper registers, an Excel stock sheet, or desktop software installed on one machine in the corner of the lab.
Without Shonit
- Donor register written by hand, then copied out again at month end
- Someone re-types the month's figures into a portal from a printout
- Stock counted off a spreadsheet that is already stale by the afternoon
- Camp forms come back in a bag and get keyed in three days later
- Whether a unit was tested depends on someone remembering
- Near-expiry units are noticed after they expire
- Performance indicators calculated by hand for an assessment
- A corrected result overwrites the old one and leaves no trace
With Shonit
- The donor register fills itself at registration and prints for any date range
- eRaktKosh data is generated from the bags you already entered
- Tested and untested stock live, by group and component, with expiry flagged
- Camp donors register on a shared link; bags reconcile to the camp they came from
- An untested unit cannot be allotted — the system refuses, it does not warn
- Units expiring within seven days appear on the home screen
- Performance indicators recalculate as the work is recorded
- Corrections keep their own register, and every record carries who changed it
From camp to donor to bag to centre
Camps are scheduled on a calendar, run from their own detail screen, and reconciled back to the centre. Donors can register themselves before they arrive through a link or QR code the organiser shares, so the queue at the desk is shorter than the queue at the chair.
- Digital donor registration — a public, per-camp registration link with a QR code, no login needed for the donor.
- Screening and deferrals — questionnaire, vitals and deferral reasons captured against the donor, not on a loose form.
- Bag reconciliation — bags are entered against the camp, so projected versus actual collection is a report rather than an argument.
- Camp reporting — camp list, site-wise collection, age and gender distribution, blood group distribution, TTI-reactive distribution, post-camp information.
- In-house sessions tracked separately from camps, so camp performance is not flattered by walk-ins.
One donor identity, not four spellings of the same name
A donor is a record with a history attached — donations, deferrals, adverse reactions, reports — rather than a row re-created at every visit. Registering through the ABHA flow verifies who they are and brings their demographics with them.
ABHA support covers verified donor registration and identity linkage. It is not a claim of full ABDM health-record exchange.
Where AI would save a job, and where it would just be decoration
Being straight about this: the capabilities below are planned, not shipped. Shonit today does not include an AI assistant, document extraction or forecasting. We would rather say so here than have you discover it in a demo.
Ask your own data
A plain-language question — “how many O-negative units are available?”, “which group is lowest on stock?”, “how many units expired this month?” — answered from your centre's own records, with the units behind the answer listed.
PlannedFill a form from a photograph
Photograph a completed paper donor form at a camp and let the fields populate themselves, for the queue that does not wait for typing. Camp registration is where this would pay for itself first.
PlannedCompliance gap check
Compare what your records contain against what an assessment expects and list what is missing — while there is still time to fix it, rather than on the day.
PlannedWhat you can do today, without AI
Everything those questions ask for already exists as a report or a screen. The dashboard answers stock and expiry questions live; the MIS reports answer period questions for any date range; the registers answer the audit questions. AI would change how you ask, not whether the answer is there.
Connects to what your centre already runs on
The portals you report to, the ways you reach donors and the systems your own developers might want to talk to. Only what Shonit actually supports is listed below.
An eRaktKosh Data report and register built from the bags, tests and issues already recorded, exportable for submission.
ABHA-verified donor registration, with the ABHA linked to the donor record and duplicates refused.
Send a donor their blood report or donation certificate on WhatsApp. Configured per deployment; where it is not configured, Shonit says so instead of pretending it sent.
Payment collection against bills through a payment gateway, reconciled into the accounting and payment summary reports.
The whole product runs on a documented REST API with an OpenAPI schema, so your own systems can read and write against it.
Compatibility and composite labels print from the issue screen, and camp registration links carry a scannable QR code.
Every register and report exports to Excel or PDF, and data can be taken out in standard formats whenever you want it.
Staff can sign in with Google where your deployment enables it, alongside email and password.
Lab analyser interfacing, hospital HIS/EMR connectors and ISBT 128 labelling are not part of Shonit today. If one of them is a requirement, tell us in the demo request and we will be straight about the timeline.
Donor and patient records, handled like patient records
A blood centre hands its software every donor identity it holds and every recipient's transfusion history. Access control and the audit trail are part of the product, not an add-on module.
Technician, supervisor, medical officer, motivation and general staff see different screens and can take different actions. Validation, shifting to tested stock and discards are supervisor-level by design.
Shonit is multi-tenant: every query is scoped to the active centre, so one centre's donors, stock and registers are never visible from another.
Who added, changed or deleted what, and when — kept per module, with history feeds on camps, reception and store, and separate correction registers for grouping, TTI and components.
Token-based sign-in with hashed passwords, password reset, and optional Google sign-in. Configuration is validated at start-up, so a misconfigured deployment fails to boot rather than running open.
Every register and report exports to Excel, CSV or PDF on demand. There is no lock-in beyond the product being useful.
Shonit ships as containers with a managed database, so it can run as a hosted service or inside infrastructure your institution controls.
Encryption in transit, backup schedules and hosting location are properties of the deployment you choose, and we will document exactly what yours does. Shonit does not currently claim any third-party security certification.
Configuration, migration, training — in that order
A single centre with clean data moves quickly; a multi-centre network takes longer, because register formats and unit numbering usually differ between centres and have to be reconciled before go-live rather than after. Here is the shape of it.
Configuration
- Centre created, with its own numbering and register formats
- Users, roles and permissions set up per designation
- Components, charges, hospitals and directory configured
Data migration
- Donor records and donation history imported
- Deferrals and existing back stock reconciled against your registers
- Opening balances checked before anything goes live
Training & go-live
- Staff trained on their own workflow, across the shifts they work
- A parallel run against your existing records
- Go live — you keep your current system running alongside as long as you want
We deliberately do not print a “live in N days” promise here. Timelines depend on how much history is migrated and how many centres are involved — we will give you a dated plan after looking at your data, and put it in writing.
Pricing
Pricing depends on the number of centres, users and modules, and on whether you want Shonit hosted for you or deployed inside your own infrastructure. Tell us the shape of your operation and we will quote against it — no per-seat surprise at renewal.
Questions we get asked most
What is Shonit?
Is Shonit cloud-based?
Can Shonit manage more than one blood centre?
Does Shonit handle inventory and component management?
Which reports and registers can Shonit generate?
Does Shonit support eRaktKosh?
Does Shonit support ABHA / ABDM?
Can Shonit stop an untested unit being issued?
Does Shonit support blood donation camps?
Can we migrate from our existing software?
How does Shonit handle security?
Can users have different roles and permissions?
Does Shonit have an API?
Does Shonit have AI features?
What hardware do we need?
How does pricing work?
Is there a demo or a trial?
What happens to our data if we leave?
Ready to modernise your blood centre?
Tell us how your centre works today — how many bags a month, which components you prepare, what your registers have to look like, how many centres are involved. The demo is run against that, not from a script.
- Walked through the workflow your staff actually run, screen by screen
- A straight answer on anything Shonit does not do yet
- A migration and go-live plan with dates on it, in writing
Request a demo
We usually reply the same working day.