Engineering

How we engineer for compliance, not just claim it

Any blood bank system can put "compliant" on a slide. The harder question is whether the software can prove its safety rules still hold — on every change, not just on the day it was certified. Here's how we approach that.

Blood banking in India sits under the Drugs & Cosmetics Act and Schedule F, ISBT 128 identification, and, for software, the direction of travel toward CDSCO's Software-as-a-Medical-Device framework. Those are real obligations. But a regulation on paper is only as good as the system's ability to keep honoring it after the auditor leaves. We designed VenaShield so the safety rules are properties of the software that can be re-checked at any time — not promises.

1. Safety rules live in code, on the server

The rules that protect patients aren't configuration toggles or front-end validations that a determined user can bypass. They're enforced server-side, where the client can't route around them:

• Segregation of Duties. The Medical Officer who releases a unit cannot be the technologist who tested it. The server checks this and returns a hard refusal if the same user attempts both.
• The reactive-unit invariant. A reactive infection screen marks a unit UNSUITABLE, and an UNSUITABLE unit can never be released, cross-matched or issued — there is no path in the code that lets it slip back into stock.
• The Rh-negative hard block in serology. An Rh(D)-negative patient grouping is always routed to a Medical Officer for weak-D confirmation before it can be validated — the system won't quietly label a patient Rh-negative on a single reading.
• Site isolation and least privilege. Non-global roles only ever see and touch their own centre's data, and each role can do exactly what its job requires and no more.

2. An audit trail you can't quietly edit

Every meaningful action is written to an audit log with the actor and the before/after values, retained for years. The important part isn't that we log — everyone logs. It's that the application physically cannot alter or delete those entries.

3. A compliance suite that runs on every single change

This is the part we're proudest of. VenaShield ships with an end-to-end compliance test suite that plays out the whole vein-to-vein chain across multiple staff roles and asserts the safety invariants hold. It doesn't just check the happy path — it checks that the wrong things are refused:

• that a phlebotomist cannot record test results or issue units;
• that a tester cannot release the unit they tested (SoD);
• that a reactive unit is never released or cross-matched;
• that an Rh-negative grouping is hard-blocked to Medical Officer review;
• that national-directive billing exemptions bill at zero;
• that inter-bank inward units can't enter stock without inspection;
• and that the whole chain lands in the audit trail.

That suite runs automatically before every change is accepted, on top of a strict code-coverage gate. If a change would break a safety rule — even accidentally — it doesn't get in. Compliance stops being a one-time certificate and becomes something we re-verify continuously.

The goal isn't to be able to say we were compliant once. It's to make "still compliant" a thing the machine checks for us, every day.

4. Boring, on purpose

A lot of this is deliberately unglamorous — explicit validation, hard refusals, retained history, tests that assert the negative case. In most software that would be over-engineering. In software that stands between a donor and a patient, it's the point. We'd rather the system be predictable and provable than clever.