BloodBank.software · Blood bank LIS

Blood bank LIS: new software, established team

BloodBank.software is a self-hosted, open source blood bank laboratory information system, first released in 2026. It is written in TypeScript on Next.js, NestJS and MongoDB, and it is built by GegoSoft — a software company that has been shipping and maintaining production systems since 2017.

Looking for the platform, modules, use cases or a demo?

Go to bloodbank.software →

Discuss an adaptation How it is built

BloodBank.software inventory and donor dashboard

Where it stands

A 2026 product, and we would rather say so

Most vendors in this category hide a new product behind the language of maturity. BloodBank.software was first released in 2026, and the honest position is that this changes what you are buying — in both directions.

What it means

You are early

There is no decade of field history behind this codebase and no long list of installations to point at. If your procurement process requires a fifteen-year reference list, we are not the right answer and we will say so early.

What there is instead: a small, readable codebase, a public repository you can audit before committing, and a system that has not yet accumulated a decade of compromises.

What it also means

You have influence

An institution deploying now talks to the engineers who wrote the system, not to a support tier. Requirements raised early tend to become part of the product rather than a private fork you maintain alone.

The team is not new. GegoSoft has built and maintained production software since 2017, including a school ERP that has been running in institutions since 2021.

Architecture

Built the way a system you have to integrate should be built

A blood bank LIS does not live alone. It has to talk to the hospital information system, to analysers, and to whatever reporting the country requires. Those constraints shaped the architecture rather than being retrofitted onto it.

01

TypeScript end to end

Next.js on the front, NestJS on the back, MongoDB underneath, Tailwind for the interface. One language across the stack means a change to a data contract surfaces at compile time rather than in a hospital at three in the morning.

02

API-first, not API-eventually

Every capability is exposed through a documented API before any screen consumes it. That is what makes integration with an HIS, an EHR or a lab analyser normal work rather than a middleware project.

03

Self-hosted by design

The institution runs it on its own servers, against its own database. Donor and patient data does not cross a border or sit in a vendor's cloud, which removes an entire category of compliance argument before it starts.

Built with AI assistance, on a stated boundary. Our engineers use Claude Code as standard daily tooling — scaffolding, test generation, static analysis triage, refactoring, documentation and review passes. AI does not approve merges, choose architecture, or deploy to production. In clinical software that boundary matters more than the speed does, so we publish it rather than leave it implied.

Adaptation

Blood banking is regulated locally. The software has to follow.

Donor eligibility rules, deferral periods, testing panels, labelling and haemovigilance reporting all change with the country. A product that assumes one regulatory environment is a product you fight. Adapting to yours is the work we do.

Country standards and reporting

Regulatory reports, record formats and retention rules rebuilt to what your authority actually asks for, rather than to a template written for somewhere else.

Donor eligibility and deferral rules

Screening questions, deferral periods and eligibility logic configured or coded to your national guidelines.

Analyser and instrument integration

Haematology and immunohaematology instruments connected so results arrive without manual re-entry. Built against the API, not into the database.

HIS and EHR integration

Orders in, results out, against whatever the hospital already runs. We scope the integration against the actual system rather than promising a named one.

Workflow and interface changes

Screens and process flows shaped to how your transfusion service works. Our team designs the screens before the API is written, then builds to what was agreed.

New modules and migration

Capabilities the product does not have yet, and moving donor records, inventory history and test results off a legacy LIS or spreadsheets.

Licensing in one line: the software is AGPL-3.0 with an additional attribution term, and it is free to take and run. The full terms, including what they require of anyone extending it, are set out on bloodbank.software. Read them before planning a private fork.

Where responsibility sits

Software supports your compliance. It cannot hold your certification.

This is worth being blunt about, because the category is full of vendors implying otherwise.

What the software does

Maintains audit trails, records the data your reporting obligations depend on, enforces role-based access, and produces the documentation an inspection asks to see.

What it does not do

Certify your facility. Accreditation and regulatory approval belong to the institution and its processes. No software product confers them, and we will not claim that ours does.

In India

The relevant framework for personal data is the Digital Personal Data Protection Act 2023. The hospital or blood centre is the Data Fiduciary; a self-hosted platform running on your infrastructure sits as a Data Processor. Full enforcement lands on 13 May 2027.

Self-hosting matters here. Donor and patient data stays on your servers, under your governance, which is a materially simpler position than a cross-border cloud.

Elsewhere

Requirements differ by country, and so do the reports. Tell us which authority you answer to and we will scope what the system needs to produce.

Next step

Two different questions, two different places

If you are evaluating the platform itself, the product site has the modules, use cases and demo. If you are asking whether it can be made to fit your country's standards and your hospital's systems, that conversation is with us.

Discuss an adaptation Platform and demo →

Tell us the institution, the country whose standards you work to, and the systems it has to connect with. That is enough for a first answer.